From report at bugs.python.org  Wed Jan  1 01:12:20 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jan 2020 06:12:20 +0000
Subject: [issue37032] Add CodeType.replace() method
In-Reply-To: <1558689955.85.0.932624363868.issue37032@roundup.psfhosted.org>
Message-ID: <1577859140.42.0.400969565907.issue37032@roundup.psfhosted.org>


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


----------
pull_requests: +17212
pull_request: https://github.com/python/cpython/pull/17779

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

From report at bugs.python.org  Wed Jan  1 01:50:22 2020
From: report at bugs.python.org (Dominic Mayers)
Date: Wed, 01 Jan 2020 06:50:22 +0000
Subject: [issue39171] Missing default root in tkinter simpledialog.py
In-Reply-To: <1577780147.06.0.429247944585.issue39171@roundup.psfhosted.org>
Message-ID: <1577861422.75.0.719265816888.issue39171@roundup.psfhosted.org>


Dominic Mayers <dominic_mayers at yahoo.com> added the comment:

Just to add that I realize now that tkinter is designed for applications with a root window, the "application window". That's why little attention is given to a possible missing root. In fact, it's interesting that we have this code in simpledialog.py: 

     
        # Here, if parent is None, we have a run time error.
        if parent.winfo_viewable():
            self.transient(parent)
 
        if title:
            self.title(title)

        self.parent = parent

        self.result = None

        body = Frame(self)
        self.initial_focus = self.body(body)
        body.pack(padx=5, pady=5)

        self.buttonbox()

        if not self.initial_focus:
            self.initial_focus = self

        self.protocol("WM_DELETE_WINDOW", self.cancel)

        if self.parent is not None:
            self.geometry("+%d+%d" % (parent.winfo_rootx()+50,
                                      parent.winfo_rooty()+50))


But, self.parent will never be None. So the geometry always depends on the parent, which is compatible with the view that we are within an application with a root window - there is always a parent.

But it contradicts a bit, in my view, the "simple" in "simpledialog". What about an application with no root window, like git for example, but which, unlike git,  needs to create a simple dialog in some occasions?

----------

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

From report at bugs.python.org  Wed Jan  1 02:21:44 2020
From: report at bugs.python.org (Dominic Mayers)
Date: Wed, 01 Jan 2020 07:21:44 +0000
Subject: [issue39177] In tkinter, simple dialogs, askstrings,
 etc. with flexible coordinates and no viewable parent.
Message-ID: <1577863304.66.0.670645943584.issue39177@roundup.psfhosted.org>


New submission from Dominic Mayers <dominic_mayers at yahoo.com>:

Currently, it's not possible to center or change the coordinates in anyway of an askstring, askfloat or askinteger dialog in simpledialog.py. One can see this by looking at the code:

        if parent.winfo_viewable():
            self.transient(parent)

        if title:
            self.title(title)

        self.parent = parent

        self.result = None

        body = Frame(self)
        self.initial_focus = self.body(body)
        body.pack(padx=5, pady=5)

        self.buttonbox()

        if not self.initial_focus:
            self.initial_focus = self

        self.protocol("WM_DELETE_WINDOW", self.cancel)

        if self.parent is not None:
            self.geometry("+%d+%d" % (parent.winfo_rootx()+50,
                                      parent.winfo_rooty()+50))

Here self.parent is never None, because the first statement would create a run time error if parent was None. So, the geometry always depends on the parent. Moreover, if the parent is not viewable, `parent.winfo_rootx()` and `parent.winfo_rooty()` are both 0. So, we can only set the coordinates of a simple dialog using a viewable parent. This contradicts a bit "simple" in "simpledialog". For example, what about an application that does not have a root window, like git for example, but, which unlike git, needs to create simple dialogs in some occasions. 

I am aware that a messagebox does not use the code that is presented above, but a messagebox is not a simple dialog - it's only a message. 

I am also aware of the class SimpleDialog, which also does not use this code, but it only works with buttons. It's not like askstring, askinteger and askfloat.

----------
messages: 359147
nosy: dominic108
priority: normal
severity: normal
status: open
title: In tkinter, simple dialogs, askstrings, etc. with flexible coordinates and no viewable parent.
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Jan  1 03:39:08 2020
From: report at bugs.python.org (sam jonas)
Date: Wed, 01 Jan 2020 08:39:08 +0000
Subject: [issue38750] Solve IPv4 categorisation issues with the ipaddress
 module
In-Reply-To: <1573247171.82.0.693534364371.issue38750@roundup.psfhosted.org>
Message-ID: <1577867948.61.0.257592201239.issue38750@roundup.psfhosted.org>


sam jonas <samjonas817 at gmail.com> added the comment:

Hi i am also facing the same issue, please provide a good solution

----------
nosy: +samjonas

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

From report at bugs.python.org  Wed Jan  1 03:42:43 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Jan 2020 08:42:43 +0000
Subject: [issue39171] Missing default root in tkinter simpledialog.py
In-Reply-To: <1577780147.06.0.429247944585.issue39171@roundup.psfhosted.org>
Message-ID: <1577868163.56.0.694036190362.issue39171@roundup.psfhosted.org>


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


----------
nosy: +gpolo, serhiy.storchaka

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

From report at bugs.python.org  Wed Jan  1 03:49:30 2020
From: report at bugs.python.org (SilentGhost)
Date: Wed, 01 Jan 2020 08:49:30 +0000
Subject: [issue39173] _AttributeHolder of argparse should support the sort
 function or not?
In-Reply-To: <1577805833.81.0.166775558073.issue39173@roundup.psfhosted.org>
Message-ID: <1577868570.81.0.545240348147.issue39173@roundup.psfhosted.org>


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

You'd need to elaborate on that. I've been using argparse for years and never once had presentational aspects affected by work. So, again, what is the actual use case for this?

----------

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

From report at bugs.python.org  Wed Jan  1 04:47:08 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 01 Jan 2020 09:47:08 +0000
Subject: [issue38871] lib2to3 generates invalid code with filter and ternary
 operator
In-Reply-To: <1574291556.7.0.332589714744.issue38871@roundup.psfhosted.org>
Message-ID: <1577872028.58.0.374330782107.issue38871@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


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

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

From report at bugs.python.org  Wed Jan  1 05:20:56 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 01 Jan 2020 10:20:56 +0000
Subject: [issue39166] Python 3.9.0a2 changed how "async for" traces its final
 iteration
In-Reply-To: <1577712159.27.0.774322517863.issue39166@roundup.psfhosted.org>
Message-ID: <1577874056.69.0.674821563903.issue39166@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Ned, can you confirm that the trace has changed from 3.8 to 3.9?

The bytecode for `doit_async` is identical for 3.8 and 3.9.

----------

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

From report at bugs.python.org  Wed Jan  1 05:53:17 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Wed, 01 Jan 2020 10:53:17 +0000
Subject: [issue39166] Python 3.9.0a2 changed how "async for" traces its final
 iteration
In-Reply-To: <1577712159.27.0.774322517863.issue39166@roundup.psfhosted.org>
Message-ID: <1577875997.15.0.522185868649.issue39166@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

I see that you are right, the bytecode is the same in 3.8 and 3.9. Nevertheless, the trace has definitely changed.  Using the same program from the top of the issue, here are the ends of the traces for a number of Python versions.  The extra trace of line 32 appears in 3.9.0a2:


$ for v in 3.6.9 3.7.4 3.8.1 3.9.0a1 3.9.0a2; do printf "\n--------\n"; $(pythonz locate $v) -c "import sys; print(sys.version)"; $(pythonz locate $v) /tmp/bpo2.py | tail -10; done

--------
3.6.9 (default, Jul 29 2019, 08:21:55)
[GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.10.44.4)]
line 21:             return next(self._it)
exce 21:             return next(self._it)
line 22:         except StopIteration:
line 23:             raise StopAsyncIteration
exce 23:             raise StopAsyncIteration
retu 23:             raise StopAsyncIteration
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 33:     print(".")
.
retu 33:     print(".")

--------
3.7.4 (default, Jul 11 2019, 19:53:42)
[Clang 10.0.0 (clang-1000.10.44.4)]
line 21:             return next(self._it)
exce 21:             return next(self._it)
line 22:         except StopIteration:
line 23:             raise StopAsyncIteration
exce 23:             raise StopAsyncIteration
retu 23:             raise StopAsyncIteration
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 33:     print(".")
.
retu 33:     print(".")

--------
3.8.1 (default, Dec 19 2019, 08:38:38)
[Clang 10.0.0 (clang-1000.10.44.4)]
line 21:             return next(self._it)
exce 21:             return next(self._it)
line 22:         except StopIteration:
line 23:             raise StopAsyncIteration
exce 23:             raise StopAsyncIteration
retu 23:             raise StopAsyncIteration
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 33:     print(".")
.
retu 33:     print(".")

--------
3.9.0a1 (default, Nov 20 2019, 18:52:14)
[Clang 10.0.0 (clang-1000.10.44.4)]
line 21:             return next(self._it)
exce 21:             return next(self._it)
line 22:         except StopIteration:
line 23:             raise StopAsyncIteration
exce 23:             raise StopAsyncIteration
retu 23:             raise StopAsyncIteration
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 33:     print(".")
.
retu 33:     print(".")

--------
3.9.0a2 (default, Dec 19 2019, 08:42:29)
[Clang 10.0.0 (clang-1000.10.44.4)]
exce 21:             return next(self._it)
line 22:         except StopIteration:
line 23:             raise StopAsyncIteration
exce 23:             raise StopAsyncIteration
retu 23:             raise StopAsyncIteration
exce 31:     async for letter in AsyncIteratorWrapper("ab"):
line 32:         print(letter)
line 33:     print(".")
.
retu 33:     print(".")

$

----------

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

From report at bugs.python.org  Wed Jan  1 06:48:53 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 01 Jan 2020 11:48:53 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple
 api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1577879333.34.0.429121304006.issue1820@roundup.psfhosted.org>


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


----------
pull_requests: +17214
pull_request: https://github.com/python/cpython/pull/17773

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

From report at bugs.python.org  Wed Jan  1 07:12:42 2020
From: report at bugs.python.org (Justin Hodder)
Date: Wed, 01 Jan 2020 12:12:42 +0000
Subject: [issue39175] Funkness with issubset
In-Reply-To: <1577841093.35.0.83643957986.issue39175@roundup.psfhosted.org>
Message-ID: <1577880762.49.0.303146284716.issue39175@roundup.psfhosted.org>


Justin Hodder <draltaicaphone at gmail.com> added the comment:

AttributeError: 'tuple' object has no attribute 'issubset'

And it doesn't explain why it works as expected in Brython.

----------

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

From report at bugs.python.org  Wed Jan  1 07:17:38 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Jan 2020 12:17:38 +0000
Subject: [issue39166] Python 3.9.0a2 changed how "async for" traces its final
 iteration
In-Reply-To: <1577712159.27.0.774322517863.issue39166@roundup.psfhosted.org>
Message-ID: <1577881058.03.0.515989536794.issue39166@roundup.psfhosted.org>


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


----------
nosy: +asvetlov, yselivanov

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

From report at bugs.python.org  Wed Jan  1 07:37:59 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Jan 2020 12:37:59 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple
 api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1577882279.59.0.0515399786472.issue1820@roundup.psfhosted.org>


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


----------
pull_requests:  -17214

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

From report at bugs.python.org  Wed Jan  1 07:43:20 2020
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Wed, 01 Jan 2020 12:43:20 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1577882600.94.0.40252001372.issue39165@roundup.psfhosted.org>


Juancarlo A?ez <apalala at gmail.com> added the comment:

The discussion on python-ideas favored the inclusion of `findfirst()`. At any rate, not having a generator version of `findall()` is an important omission.

Another user's search of Github public repositories found that `findall(...)[0]` is prevalent. python-ideas agreed that the cause was the incompleteness/asymmetry in `re`.

----------

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

From report at bugs.python.org  Wed Jan  1 08:30:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Jan 2020 13:30:24 +0000
Subject: [issue39166] Python 3.9.0a2 changed how "async for" traces its final
 iteration
In-Reply-To: <1577712159.27.0.774322517863.issue39166@roundup.psfhosted.org>
Message-ID: <1577885424.17.0.958497677138.issue39166@roundup.psfhosted.org>


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

Bisecting points me to fee552669f . I tried compiling latest master with the bytecode changes and the behavior is same as reported.

?  cpython git:(5dcc06f6e0) ./python ../backups/bpo39166.py > fee552669f_before.txt
?  cpython git:(5dcc06f6e0) ? git checkout fee552669f                                
?  cpython git:(fee552669f) ? make -s -j4 > /dev/null 
?  cpython git:(fee552669f) ? ./python ../backups/bpo39166.py > fee552669f.txt       
?  cpython git:(fee552669f) ? diff fee552669f.txt fee552669f_before.txt 
1c1
< 3.9.0a1+ (tags/v3.9.0a1-43-gfee552669f:fee552669f, Jan  1 2020, 18:51:56) 
---
> 3.9.0a1+ (tags/v3.9.0a1-42-g5dcc06f6e0:5dcc06f6e0, Jan  1 2020, 18:49:53) 
47d46
< line 33:         print(letter)

With master

?  cpython git:(master) ./python ../backups/bpo39166.py > master.txt
?  cpython git:(master) ? diff fee552669f_before.txt master.txt
1c1
< 3.9.0a1+ (tags/v3.9.0a1-42-g5dcc06f6e0:5dcc06f6e0, Jan  1 2020, 18:49:53) 
---
> 3.9.0a2+ (heads/master:22424c02e5, Jan  1 2020, 18:55:29) 
46a47
> line 33:         print(letter)

----------
nosy: +serhiy.storchaka, xtreak

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

From report at bugs.python.org  Wed Jan  1 09:00:21 2020
From: report at bugs.python.org (Adi)
Date: Wed, 01 Jan 2020 14:00:21 +0000
Subject: [issue39178] Should we make dict not accept a sequence of sets?
Message-ID: <1577887221.9.0.378714052511.issue39178@roundup.psfhosted.org>


New submission from Adi <deepspace2 at gmail.com>:

While writing this SO answer (https://stackoverflow.com/a/59552970/1453822) I came to think, should dict preemptively make sure it doesn't accept a sequence of sets (given that it may lead to wrong output in the good case, and miserably fail in the worst case)?

----------
messages: 359155
nosy: DeepSpace
priority: normal
severity: normal
status: open
title: Should we make dict not accept a sequence of sets?
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Jan  1 09:09:56 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Jan 2020 14:09:56 +0000
Subject: [issue39178] Should we make dict not accept a sequence of sets?
In-Reply-To: <1577887221.9.0.378714052511.issue39178@roundup.psfhosted.org>
Message-ID: <1577887796.57.0.887294773326.issue39178@roundup.psfhosted.org>


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


----------
nosy: +inada.naoki, rhettinger

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

From report at bugs.python.org  Wed Jan  1 09:22:26 2020
From: report at bugs.python.org (seeking.that)
Date: Wed, 01 Jan 2020 14:22:26 +0000
Subject: [issue39179] pandas tz_convert() seems to report incorrect date
 conversion
Message-ID: <1577888546.9.0.841265032585.issue39179@roundup.psfhosted.org>


New submission from seeking.that <seeking.that at gmail.com>:

Hi

python pandas bdate_range tz_convert() seems to have problems as it prints the information incorrectly. Please clarity. The python script and the output is shown below:

Two issues that can be highlighted here are:
1) Setting the timezone correctly to US/Pacific prints the dates correctly. But the conversion causes the date calculations to be incorrect.
2. Minor issue just related to display. Though the API hasn't changed, the last call has more information hh-mm-ss-xx-xx which is not there for the rest of the calls with same format signature.

Thanks
SK
import pandas as pd

c5 = pd.bdate_range(start='1/1/2018', end = '1/31/2018')
print(c5)
c5 = c5.tz_localize('UTC')
print(c5)
c5 = c5.tz_convert('US/Pacific')
print(c5)
c6 = pd.bdate_range(start='1/1/2018', end = '1/31/2018')
print(c6)
c6 = c6.tz_localize('US/Pacific')
print(c6)
------

DatetimeIndex(['2018-01-01', '2018-01-02', '2018-01-03', '2018-01-04',
               '2018-01-05', '2018-01-08', '2018-01-09', '2018-01-10',
               '2018-01-11', '2018-01-12', '2018-01-15', '2018-01-16',
               '2018-01-17', '2018-01-18', '2018-01-19', '2018-01-22',
               '2018-01-23', '2018-01-24', '2018-01-25', '2018-01-26',
               '2018-01-29', '2018-01-30', '2018-01-31'],
              dtype='datetime64[ns]', freq='B')
DatetimeIndex(['2018-01-01', '2018-01-02', '2018-01-03', '2018-01-04',
               '2018-01-05', '2018-01-08', '2018-01-09', '2018-01-10',
               '2018-01-11', '2018-01-12', '2018-01-15', '2018-01-16',
               '2018-01-17', '2018-01-18', '2018-01-19', '2018-01-22',
               '2018-01-23', '2018-01-24', '2018-01-25', '2018-01-26',
               '2018-01-29', '2018-01-30', '2018-01-31'],
              dtype='datetime64[ns, UTC]', freq='B')
DatetimeIndex(['2017-12-31', '2018-01-01', '2018-01-02', '2018-01-03',
               '2018-01-04', '2018-01-07', '2018-01-08', '2018-01-09',
               '2018-01-10', '2018-01-11', '2018-01-14', '2018-01-15',
               '2018-01-16', '2018-01-17', '2018-01-18', '2018-01-21',
               '2018-01-22', '2018-01-23', '2018-01-24', '2018-01-25',
               '2018-01-28', '2018-01-29', '2018-01-30'],
              dtype='datetime64[ns, US/Pacific]', freq='B')
DatetimeIndex(['2018-01-01', '2018-01-02', '2018-01-03', '2018-01-04',
               '2018-01-05', '2018-01-08', '2018-01-09', '2018-01-10',
               '2018-01-11', '2018-01-12', '2018-01-15', '2018-01-16',
               '2018-01-17', '2018-01-18', '2018-01-19', '2018-01-22',
               '2018-01-23', '2018-01-24', '2018-01-25', '2018-01-26',
               '2018-01-29', '2018-01-30', '2018-01-31'],
              dtype='datetime64[ns]', freq='B')
DatetimeIndex(['2018-01-01 00:00:00-08:00', '2018-01-02 00:00:00-08:00',
               '2018-01-03 00:00:00-08:00', '2018-01-04 00:00:00-08:00',
               '2018-01-05 00:00:00-08:00', '2018-01-08 00:00:00-08:00',
               '2018-01-09 00:00:00-08:00', '2018-01-10 00:00:00-08:00',
               '2018-01-11 00:00:00-08:00', '2018-01-12 00:00:00-08:00',
               '2018-01-15 00:00:00-08:00', '2018-01-16 00:00:00-08:00',
               '2018-01-17 00:00:00-08:00', '2018-01-18 00:00:00-08:00',
               '2018-01-19 00:00:00-08:00', '2018-01-22 00:00:00-08:00',
               '2018-01-23 00:00:00-08:00', '2018-01-24 00:00:00-08:00',
               '2018-01-25 00:00:00-08:00', '2018-01-26 00:00:00-08:00',
               '2018-01-29 00:00:00-08:00', '2018-01-30 00:00:00-08:00',
               '2018-01-31 00:00:00-08:00'],
              dtype='datetime64[ns, US/Pacific]', freq='B')

----------
messages: 359156
nosy: Seeking.that
priority: normal
severity: normal
status: open
title: pandas tz_convert() seems to report incorrect date conversion
versions: Python 3.6

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

From report at bugs.python.org  Wed Jan  1 09:25:44 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Jan 2020 14:25:44 +0000
Subject: [issue39178] Should we make dict not accept a sequence of sets?
In-Reply-To: <1577887221.9.0.378714052511.issue39178@roundup.psfhosted.org>
Message-ID: <1577888744.36.0.0872491000894.issue39178@roundup.psfhosted.org>


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

This is a very special case. I think it is better to leave it to third-party linters.

Actually it is so uncommon, that I have doubts that even linters will want to handle it.

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

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

From report at bugs.python.org  Wed Jan  1 09:29:09 2020
From: report at bugs.python.org (Khalid Mammadov)
Date: Wed, 01 Jan 2020 14:29:09 +0000
Subject: [issue39180] Missing getlines func documentation from linecache module
Message-ID: <1577888949.55.0.96578961298.issue39180@roundup.psfhosted.org>


Change by Khalid Mammadov <khalidmammadov9 at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, khalidmammadov
priority: normal
severity: normal
status: open
title: Missing getlines func documentation from linecache module
versions: Python 3.8

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

From report at bugs.python.org  Wed Jan  1 09:33:06 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Jan 2020 14:33:06 +0000
Subject: [issue39179] pandas tz_convert() seems to report incorrect date
 conversion
In-Reply-To: <1577888546.9.0.841265032585.issue39179@roundup.psfhosted.org>
Message-ID: <1577889186.59.0.587114653931.issue39179@roundup.psfhosted.org>


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

This tracker is for issues related to CPython. Unless there is a simple reproducer in Python without pandas to illustrate the issues reported I would propose closing this as third party. Please follow this up at https://github.com/pandas-dev/pandas/

----------
nosy: +xtreak

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

From report at bugs.python.org  Wed Jan  1 09:38:56 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Jan 2020 14:38:56 +0000
Subject: [issue39180] Missing getlines func documentation from linecache module
Message-ID: <1577889536.91.0.731719128182.issue39180@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

As a note getlines is not exposed via __all__ : https://github.com/python/cpython/blob/22424c02e51fab3b62cbe255d0b87d1b55b9a6c3/Lib/linecache.py#L13

----------
nosy: +xtreak

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

From report at bugs.python.org  Wed Jan  1 09:45:16 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 01 Jan 2020 14:45:16 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1577889916.03.0.797156929007.issue35561@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Jan  1 09:46:22 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 01 Jan 2020 14:46:22 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1577889982.42.0.348248187716.issue35561@roundup.psfhosted.org>


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


----------
nosy: +ZackerySpytz
versions: +Python 3.9

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

From report at bugs.python.org  Wed Jan  1 09:47:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 01 Jan 2020 14:47:08 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1577890028.4.0.327811696598.issue39165@roundup.psfhosted.org>


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

This was discussed recently on the Python-ideas mailing list.

https://mail.python.org/archives/list/python-ideas at python.org/thread/M2OZCN5C26YUJJ4EXLIIXHQBGF6IM5GW/#H3GURL35C7AZ3ZBK6CQZGGCISUZ42WDV

I agree with Raymond that this is an education problem. There are occurrences of `findall(...)[0]` in real code, but most of this code has not very high quality. In all cases re.search() can be used. In some cases the code can be rewritten in much more efficient way, using a single regular expression, for example:

-   if re.search('^(\w+) (\w+)$', parcel.owner):
-     last, first = re.findall( '(\w+) (\w+)',parcel.owner )[0]
-   elif re.search('^(\w+) (\w+) (\w+)$', parcel.owner):
-     last, first, middle = re.findall( '(\w+) (\w+) (\w+)',parcel.owner )[0]
-   elif re.search('^(\w+) (\w+) &amp; (\w+)$', parcel.owner):
-     last, first = re.findall( '(\w+) (\w+)',parcel.owner )[0]
-   elif re.search('^(\w+) (\w+) (\w+) &amp: (\w+)$', parcel.owner):
-     last, first, middle = re.findall( '(\w+) (\w+) (\w+)',parcel.owner )[0]
-   elif re.search('^(\w+) (\w+) &amp; (\w+) (\w+)$', parcel.owner):
-     last, first = re.findall( '(\w+) (\w+)',parcel.owner )[0]
-   elif re.search('^(\w+) (\w+) (\w+) &amp: (\w+) (\w+)$', parcel.owner):
-     last, first, middle = re.findall( '(\w+) (\w+) (\w+)',parcel.owner )[0]
-   elif re.search('^(\w+) (\w+) &amp; (\w+) (\w+) (\w+)$', parcel.owner):
-     last, first = re.findall( '(\w+) (\w+)',parcel.owner )[0]
-   elif re.search('^(\w+) (\w+) (\w+) &amp: (\w+) (\w+) (\w+)$', parcel.owner):
-     last, first, middle = re.findall( '(\w+) (\w+) (\w+)', parcel.owner     )[0]
+   m = re.fullmatch('(\w+) (\w+)(?: (\w+))?(?: &amp;(?: \w+){1,3})?', parcel.owner)
+   if m:
+     last, first, middle = m.groups()

But even using `findall(...)[0]` is not always so bad, because in many cases findall() returns a list containing a single string.

Adding re.findfirst() will not automatically fix all existing code which uses `findall(...)[0]`. This is an education problem, you need to teach people to use the more appropriate function, and if you can teach about re.findfirst(), why can't you teach about re.search()?

----------

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

From report at bugs.python.org  Wed Jan  1 10:16:12 2020
From: report at bugs.python.org (Khalid Mammadov)
Date: Wed, 01 Jan 2020 15:16:12 +0000
Subject: [issue39180] Missing getlines func documentation from linecache module
In-Reply-To: <1577889536.91.0.731719128182.issue39180@roundup.psfhosted.org>
Message-ID: <1577891772.33.0.0495470380022.issue39180@roundup.psfhosted.org>


Change by Khalid Mammadov <khalidmammadov9 at gmail.com>:


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

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

From report at bugs.python.org  Wed Jan  1 10:44:30 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 01 Jan 2020 15:44:30 +0000
Subject: [issue39178] Should we make dict not accept a sequence of sets?
In-Reply-To: <1577887221.9.0.378714052511.issue39178@roundup.psfhosted.org>
Message-ID: <1577893470.17.0.568137170886.issue39178@roundup.psfhosted.org>


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

"should dict preemptively make sure it doesn't accept a sequence of sets"

No. The person on StackOverflow made a mistake in their code: they used an unordered data structure (set) instead of an ordered data structure (tuple):

    dict({i,j} for i,j in enumerate(lst))

It is a waste of time to slow down the dict constructor to check for something so unusual as this. Everyone will pay the cost of the checks and virtually no-one will get any benefit.

I'm closing this as "rejected", but if anyone disagrees they can reopen it.

By the way, the best way to initialise a dictionary in this situation is to avoid the unnecessary generator expression and just go straight to enumerate:

    dict(enumerate(lst))

----------
nosy: +steven.daprano
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Jan  1 11:53:16 2020
From: report at bugs.python.org (jack1142)
Date: Wed, 01 Jan 2020 16:53:16 +0000
Subject: [issue39181] Add `os.makedirs()` as `Path.mkdir()` equivalent in
 correspondence table
Message-ID: <1577897596.74.0.989558678168.issue39181@roundup.psfhosted.org>


New submission from jack1142 <kuba.kuczys at gmail.com>:

https://github.com/python/cpython/blob/3.7/Doc/library/pathlib.rst#correspondence-to-tools-in-the-modos-module

The table mapping `os` functions to `Path`'s equivalents is missing `os.makedirs` in the row with `Path.mkdir()` and they are both equivalent when `Path.mkdir()` is used with `parents=True` kwarg.

I can make a PR once this gets triaged, I'm not sure if this doc improvement should only be made to master branch or also 3.7/3.8 so let me know about that too, thanks.

----------
assignee: docs at python
components: Documentation
messages: 359162
nosy: docs at python, jack1142
priority: normal
severity: normal
status: open
title: Add `os.makedirs()` as `Path.mkdir()` equivalent in correspondence table
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jan  1 12:10:09 2020
From: report at bugs.python.org (Alexander Hirner)
Date: Wed, 01 Jan 2020 17:10:09 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1577898609.93.0.170287199313.issue39134@roundup.psfhosted.org>


Alexander Hirner <a.hirner at gmail.com> added the comment:

Dropping ABCMeta stops at instantiation. This should be in the dataclass code that's been generated.

  File "<string>", line 2, in __init__
AttributeError: can't set attribute


Repro:
```
class QuasiABC:
    @property
    @abstractmethod
    def x(self) -> int: ...

@dataclass(frozen=True)
class E(QuasiABC):
    x: int

E(10)
```

Interestingly, frozen=False is giving the same error.

----------

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

From report at bugs.python.org  Wed Jan  1 12:23:00 2020
From: report at bugs.python.org (Dutcho)
Date: Wed, 01 Jan 2020 17:23:00 +0000
Subject: [issue39182] sys.addaudithook(hook) loops indefinitely on mismatch
 for hook
Message-ID: <1577899380.86.0.650724982572.issue39182@roundup.psfhosted.org>


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

When hook is not a compatible callable, addaudithook() will loop forever. At the minimum, a check for being callable should be executed. Preferably, a non-compatible (i.e. signature != [[str, tuple], Any]) hook callable should also be detected.

>py
Python 3.8.1 (tags/v3.8.1:1b293b6, Dec 18 2019, 23:11:46) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.addaudithook(0)
error=10
Exception ignored in audit hook:
TypeError: 'int' object is not callable
  File "<stdin>", line 0
SyntaxError: unknown parsing error
error=10
Exception ignored in audit hook:
TypeError: 'int' object is not callable
  File "<stdin>", line 0
SyntaxError: unknown parsing error
error=10
Exception ignored in audit hook:
TypeError: 'int' object is not callable
  File "<stdin>", line 0
SyntaxError: unknown parsing error
... etc. ...

----------
messages: 359164
nosy: Dutcho
priority: normal
severity: normal
status: open
title: sys.addaudithook(hook) loops indefinitely on mismatch for hook
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Jan  1 13:34:50 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 01 Jan 2020 18:34:50 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1577903690.35.0.225925782298.issue39134@roundup.psfhosted.org>


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

Try adding a setter to the base class method.

----------

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

From report at bugs.python.org  Wed Jan  1 14:19:58 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 01 Jan 2020 19:19:58 +0000
Subject: [issue39182] sys.addaudithook(hook) loops indefinitely on mismatch
 for hook
In-Reply-To: <1577899380.86.0.650724982572.issue39182@roundup.psfhosted.org>
Message-ID: <1577906398.71.0.755954661558.issue39182@roundup.psfhosted.org>


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


----------
nosy: +christian.heimes, steve.dower

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

From report at bugs.python.org  Wed Jan  1 14:32:24 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 01 Jan 2020 19:32:24 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
In-Reply-To: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>
Message-ID: <1577907144.82.0.728316555462.issue39142@roundup.psfhosted.org>


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


New changeset 46abfc1416ff8e450999611ef8f231ff871ab133 by Vinay Sajip in branch 'master':
bpo-39142: Avoid converting namedtuple instances to ConvertingTuple. (GH-17773)
https://github.com/python/cpython/commit/46abfc1416ff8e450999611ef8f231ff871ab133


----------

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

From report at bugs.python.org  Wed Jan  1 14:34:09 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jan 2020 19:34:09 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
In-Reply-To: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>
Message-ID: <1577907249.32.0.0611473292206.issue39142@roundup.psfhosted.org>


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


----------
pull_requests: +17217
pull_request: https://github.com/python/cpython/pull/17785

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

From report at bugs.python.org  Wed Jan  1 14:34:39 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jan 2020 19:34:39 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
In-Reply-To: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>
Message-ID: <1577907279.12.0.700344732006.issue39142@roundup.psfhosted.org>


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


----------
pull_requests: +17218
pull_request: https://github.com/python/cpython/pull/17786

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

From report at bugs.python.org  Wed Jan  1 15:06:55 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 01 Jan 2020 20:06:55 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
In-Reply-To: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>
Message-ID: <1577909215.41.0.0316814765068.issue39142@roundup.psfhosted.org>


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


New changeset 1d5a7e5694bd9104f56f4f28357c2d13afd58a29 by Vinay Sajip (Miss Islington (bot)) in branch '3.8':
bpo-39142: Avoid converting namedtuple instances to ConvertingTuple. (GH-17773) (GH-17785)
https://github.com/python/cpython/commit/1d5a7e5694bd9104f56f4f28357c2d13afd58a29


----------

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

From report at bugs.python.org  Wed Jan  1 15:07:35 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 01 Jan 2020 20:07:35 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
In-Reply-To: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>
Message-ID: <1577909255.56.0.848971791278.issue39142@roundup.psfhosted.org>


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


New changeset 0e0e4acaabdcf8efb60cf75f08301022ac4422a4 by Vinay Sajip (Miss Islington (bot)) in branch '3.7':
bpo-39142: Avoid converting namedtuple instances to ConvertingTuple. (GH-17773) (GH-17786)
https://github.com/python/cpython/commit/0e0e4acaabdcf8efb60cf75f08301022ac4422a4


----------

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

From report at bugs.python.org  Wed Jan  1 15:27:28 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 01 Jan 2020 20:27:28 +0000
Subject: [issue39142] logging.config.dictConfig will convert namedtuple to
 ConvertingTuple
In-Reply-To: <1577478792.48.0.935250050519.issue39142@roundup.psfhosted.org>
Message-ID: <1577910448.83.0.2429077182.issue39142@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Jan  1 16:36:05 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Jan 2020 21:36:05 +0000
Subject: [issue38879] Reordered error checking in PyArena_New().
In-Reply-To: <1574352752.3.0.334420443084.issue38879@roundup.psfhosted.org>
Message-ID: <1577914565.6.0.513724149387.issue38879@roundup.psfhosted.org>


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

I'm rejecting this, as explained on the Github PR.

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

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

From report at bugs.python.org  Wed Jan  1 17:06:36 2020
From: report at bugs.python.org (Rafael Fontenelle)
Date: Wed, 01 Jan 2020 22:06:36 +0000
Subject: [issue39183] Text divided in two strings due to wrong formatting
Message-ID: <1577916396.48.0.991932601877.issue39183@roundup.psfhosted.org>


New submission from Rafael Fontenelle <rffontenelle at gmail.com>:

When translating Python docs, the 'library/ensurepip' module [1] has an bullet list where one item's text is split in two due to a simple extra whitespace character. This causes two separated translations strings

"``--default-pip``: if a \"default pip\" installation is requested, the"

and

"``pip`` script will be installed in addition to the two regular scripts."

, which clearly should be a single one.

Its effect can be seen also in the resulting documentation, where these strings are shown in different lines even when there are enough space in the browser window to should it all.

Solution is to remove the extra space and formatting is good again.

[1] https://docs.python.org/3/library/ensurepip.html

----------
assignee: docs at python
components: Documentation
messages: 359170
nosy: docs at python, rffontenelle
priority: normal
severity: normal
status: open
title: Text divided in two strings due to wrong formatting
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Jan  1 17:11:33 2020
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Jan 2020 22:11:33 +0000
Subject: [issue39183] Text divided in two strings due to wrong formatting
In-Reply-To: <1577916396.48.0.991932601877.issue39183@roundup.psfhosted.org>
Message-ID: <1577916693.98.0.859506206353.issue39183@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Jan  1 17:21:49 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Jan 2020 22:21:49 +0000
Subject: [issue13601] sys.stderr should be line-buffered when stderr is not a
 TTY
In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>
Message-ID: <1577917309.65.0.674456580891.issue13601@roundup.psfhosted.org>


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


New changeset 5b9077134cd0535f21905d5f5195847526cac99c by Antoine Pitrou (Jendrik Seipp) in branch 'master':
bpo-13601: always use line-buffering for sys.stderr (GH-17646)
https://github.com/python/cpython/commit/5b9077134cd0535f21905d5f5195847526cac99c


----------

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

From report at bugs.python.org  Wed Jan  1 17:22:26 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 01 Jan 2020 22:22:26 +0000
Subject: [issue13601] sys.stderr should be line-buffered when stderr is not a
 TTY
In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>
Message-ID: <1577917346.86.0.480274919907.issue13601@roundup.psfhosted.org>


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

Jendrik, thank you for fixing this!

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

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

From report at bugs.python.org  Wed Jan  1 17:26:36 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jan 2020 22:26:36 +0000
Subject: [issue39183] Text divided in two strings due to wrong formatting
In-Reply-To: <1577916396.48.0.991932601877.issue39183@roundup.psfhosted.org>
Message-ID: <1577917596.89.0.059492921197.issue39183@roundup.psfhosted.org>


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


New changeset 149175c6dfc8455023e4335575f3fe3d606729f9 by Miss Islington (bot) (Rafael Fontenelle) in branch 'master':
bpo-39183: Fix formatting in library/ensurepip (GH-17787)
https://github.com/python/cpython/commit/149175c6dfc8455023e4335575f3fe3d606729f9


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

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

From report at bugs.python.org  Wed Jan  1 17:26:48 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jan 2020 22:26:48 +0000
Subject: [issue39183] Text divided in two strings due to wrong formatting
In-Reply-To: <1577916396.48.0.991932601877.issue39183@roundup.psfhosted.org>
Message-ID: <1577917608.64.0.526571054502.issue39183@roundup.psfhosted.org>


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


----------
pull_requests: +17221
pull_request: https://github.com/python/cpython/pull/17788

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

From report at bugs.python.org  Wed Jan  1 17:26:55 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jan 2020 22:26:55 +0000
Subject: [issue39183] Text divided in two strings due to wrong formatting
In-Reply-To: <1577916396.48.0.991932601877.issue39183@roundup.psfhosted.org>
Message-ID: <1577917615.2.0.576522622158.issue39183@roundup.psfhosted.org>


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


----------
pull_requests: +17222
pull_request: https://github.com/python/cpython/pull/17789

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

From report at bugs.python.org  Wed Jan  1 17:32:20 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jan 2020 22:32:20 +0000
Subject: [issue39183] Text divided in two strings due to wrong formatting
In-Reply-To: <1577916396.48.0.991932601877.issue39183@roundup.psfhosted.org>
Message-ID: <1577917940.78.0.448411848382.issue39183@roundup.psfhosted.org>


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


New changeset 3959638ba1b1e25c25a2da880aba78fd53dd947f by Miss Islington (bot) in branch '3.7':
bpo-39183: Fix formatting in library/ensurepip (GH-17787)
https://github.com/python/cpython/commit/3959638ba1b1e25c25a2da880aba78fd53dd947f


----------

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

From report at bugs.python.org  Wed Jan  1 17:32:27 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 01 Jan 2020 22:32:27 +0000
Subject: [issue39183] Text divided in two strings due to wrong formatting
In-Reply-To: <1577916396.48.0.991932601877.issue39183@roundup.psfhosted.org>
Message-ID: <1577917947.17.0.645519779146.issue39183@roundup.psfhosted.org>


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


New changeset 6bf382ac9a07f42c6f91f35a7f0df4c63e35a8a7 by Miss Islington (bot) in branch '3.8':
bpo-39183: Fix formatting in library/ensurepip (GH-17787)
https://github.com/python/cpython/commit/6bf382ac9a07f42c6f91f35a7f0df4c63e35a8a7


----------

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

From report at bugs.python.org  Wed Jan  1 17:54:50 2020
From: report at bugs.python.org (David Bolen)
Date: Wed, 01 Jan 2020 22:54:50 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1577919290.32.0.559737473254.issue27973@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

The issue appears to be the temporary flag (O_TEMPORARY) that is used under Windows with delete on close temporary files.  That appears to prevent any separate access to the file by anyone else including obtaining another reference in the same process:

>>> temp = tempfile.NamedTemporaryFile()
>>> temp, temp.name
(<open file '<fdopen>', mode 'w+b' at 0x017958E8>, 'd:\\temp\\tmp44kugh')
>>> other = open(temp.name, 'r')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: [Errno 13] Permission denied: 'd:\\temp\\tmp44kugh'

Changing the mode (PR 17774) of the temporary file has no effect.  Setting delete=False will work, but would defeat the point of using NamedTemporaryFile for the cleanup.

I don't see any way to have both auto-delete and the ability to write separately to a file under Windows with NamedTemporaryFile.

Perhaps instead use test.support.temp_dir for the overall test, and let it take care of the iteration temp files when cleaning up the entire directory?  Something like:

    with test_support.temp_dir() as td:
        for i in range(self.NUM_FTP_RETRIEVES):
            urllib.FancyURLopener().retrieve(self.FTP_TEST_FILE, os.path.join(td, str(i)))

That seems to work fine under Windows.

----------
nosy: +db3l

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

From report at bugs.python.org  Wed Jan  1 18:10:03 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Wed, 01 Jan 2020 23:10:03 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
Message-ID: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>


New submission from Saiyang Gou <gousaiyang223 at gmail.com>:

Similar to `os.system` (which is already raising auditing event), the following functions are also capable of command execution, so they also need auditing:

- os.execl
- os.execle
- os.execlp
- os.execlpe
- os.execv
- os.execve
- os.execvp
- os.execvpe
- os.posix_spawn
- os.posix_spawnp
- os.spawnl
- os.spawnle
- os.spawnlp
- os.spawnlpe
- os.spawnv
- os.spawnve
- os.spawnvp
- os.spawnvpe
- os.startfile
- pty.spawn

By the way, since `os.listdir`, `shutil.copytree` and `shutil.rmtree` are already being audited, is it necessary to audit file operations in the `os` module like `os.remove`?

----------
messages: 359177
nosy: Saiyang Gou
priority: normal
severity: normal
status: open
title: Many command execution functions are not raising auditing events
type: security
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jan  1 18:13:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 01 Jan 2020 23:13:59 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1577920439.21.0.260071951421.issue39184@roundup.psfhosted.org>


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


----------
nosy: +steve.dower

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

From report at bugs.python.org  Wed Jan  1 18:41:34 2020
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Jan 2020 23:41:34 +0000
Subject: [issue15795] Zipfile.extractall does not preserve file permissions
In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za>
Message-ID: <1577922094.08.0.747700614181.issue15795@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Jan  1 20:09:37 2020
From: report at bugs.python.org (anthony shaw)
Date: Thu, 02 Jan 2020 01:09:37 +0000
Subject: [issue39185] Add quiet and detailed verbosity levels to build.bat
Message-ID: <1577927377.26.0.421756435825.issue39185@roundup.psfhosted.org>


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

The build.bat script (windows build) has a flag for verbose, which sets the msbuild verbosity level to normal.
The default level is minimal.

The quiet and detailed levels would also be useful for development.

----------
components: Windows
messages: 359178
nosy: anthonypjshaw, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add quiet and detailed verbosity levels to build.bat
type: enhancement

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

From report at bugs.python.org  Wed Jan  1 20:10:19 2020
From: report at bugs.python.org (anthony shaw)
Date: Thu, 02 Jan 2020 01:10:19 +0000
Subject: [issue39185] Add quiet and detailed verbosity levels to build.bat
In-Reply-To: <1577927377.26.0.421756435825.issue39185@roundup.psfhosted.org>
Message-ID: <1577927419.43.0.715152995501.issue39185@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


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

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

From report at bugs.python.org  Wed Jan  1 21:23:44 2020
From: report at bugs.python.org (anthony shaw)
Date: Thu, 02 Jan 2020 02:23:44 +0000
Subject: [issue39186] Windows installer instructions refer to mercurial
Message-ID: <1577931824.82.0.916015771448.issue39186@roundup.psfhosted.org>


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

Very minor, but the instructions in Tools/msi/readme.txt tell the user to ensure hg.exe is in PATH, but the scripts use Git.

----------
components: Windows
messages: 359179
nosy: anthonypjshaw, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows installer instructions refer to mercurial

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

From report at bugs.python.org  Wed Jan  1 21:24:09 2020
From: report at bugs.python.org (anthony shaw)
Date: Thu, 02 Jan 2020 02:24:09 +0000
Subject: [issue39186] Windows installer instructions refer to mercurial
In-Reply-To: <1577931824.82.0.916015771448.issue39186@roundup.psfhosted.org>
Message-ID: <1577931849.77.0.445914514691.issue39186@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


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

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

From report at bugs.python.org  Wed Jan  1 22:41:13 2020
From: report at bugs.python.org (Andre Burgaud)
Date: Thu, 02 Jan 2020 03:41:13 +0000
Subject: [issue35457] robotparser reads empty robots.txt file as "all denied"
In-Reply-To: <1544520647.95.0.788709270274.issue35457@psf.upfronthosting.co.za>
Message-ID: <1577936473.45.0.756125026518.issue35457@roundup.psfhosted.org>


Andre Burgaud <andre.burgaud at gmail.com> added the comment:

Hi,

Is this ticket still relevant for Python 3.8?

While running some tests with an empty robotstxt file I realized that it was returning "ALLOWED" for any path (as per the current draft of the Robots Exclusion Protocol: https://tools.ietf.org/html/draft-koster-rep-00#section-2.2.1 ")

Code:

from urllib import robotparser

robots_url = "file:///tmp/empty.txt"

rp = robotparser.RobotFileParser()
print(robots_url)
rp.set_url(robots_url)
rp.read()
print( "fetch /", rp.can_fetch(useragent = "*", url = "/"))
print( "fetch /admin", rp.can_fetch(useragent = "*", url = "/admin"))

Output:

$ cat /tmp/empty.txt
$ python -V
Python 3.8.1
$ python test_robot3.py
file:///tmp/empty.txt
fetch / True
fetch /admin True

----------
nosy: +gallicrooster

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

From report at bugs.python.org  Wed Jan  1 23:14:05 2020
From: report at bugs.python.org (Andre Burgaud)
Date: Thu, 02 Jan 2020 04:14:05 +0000
Subject: [issue39187] urllib.robotparser does not respect the longest match
 for the rule
Message-ID: <1577938445.91.0.743054392693.issue39187@roundup.psfhosted.org>


New submission from Andre Burgaud <andre.burgaud at gmail.com>:

As per the current Robots Exclusion Protocol internet draft, https://tools.ietf.org/html/draft-koster-rep-00#section-3.2. a robot should apply the rules respecting the longest match.

urllib.robotparser relies on the order of the rules in the robots.txt file. Here is the section in the specs:

===================
3.2.  Longest Match

   The following example shows that in the case of a two rules, the
   longest one MUST be used for matching.  In the following case,
   /example/page/disallowed.gif MUST be used for the URI
   example.com/example/page/disallow.gif .

   <CODE BEGINS>
   User-Agent : foobot
   Allow : /example/page/
   Disallow : /example/page/disallowed.gif
   <CODE ENDS> 
===================

I'm attaching a simple test file "test_robot.py"

----------
components: Library (Lib)
files: test_robot.py
messages: 359181
nosy: gallicrooster
priority: normal
severity: normal
status: open
title: urllib.robotparser does not respect the longest match for the rule
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48815/test_robot.py

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

From report at bugs.python.org  Wed Jan  1 23:59:11 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 02 Jan 2020 04:59:11 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple
 api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1577941151.66.0.907660658134.issue1820@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Jan  2 00:14:33 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 02 Jan 2020 05:14:33 +0000
Subject: [issue16399] argparse: append action with default list adds to list
 instead of overriding
In-Reply-To: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za>
Message-ID: <1577942073.67.0.558715978211.issue16399@roundup.psfhosted.org>


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


----------
pull_requests: +17226
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17793

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

From report at bugs.python.org  Thu Jan  2 00:27:39 2020
From: report at bugs.python.org (Andre Burgaud)
Date: Thu, 02 Jan 2020 05:27:39 +0000
Subject: [issue39187] urllib.robotparser does not respect the longest match
 for the rule
In-Reply-To: <1577938445.91.0.743054392693.issue39187@roundup.psfhosted.org>
Message-ID: <1577942859.1.0.112337957453.issue39187@roundup.psfhosted.org>


Change by Andre Burgaud <andre.burgaud at gmail.com>:


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

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

From report at bugs.python.org  Thu Jan  2 00:35:13 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 02 Jan 2020 05:35:13 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577943313.29.0.10051633763.issue36051@roundup.psfhosted.org>


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

> In the single-threaded case, the benchmark seems to show that for 64K+, performance is improved by dropping the GIL (which I'm guessing must be statistical noise, since there shouldn't be anything contending for it), which is my reasoning behind the 65536 threshold.

Yes, single-threaded case shouldn't affected by this change.  Dropping GIL is just a very little overhead.

So you need to focus on multi-threaded case when considering threshold.
As far as seeing your result, 65536 threshold seems too small.
See 512*8192 case.  It shows 1479->980 regression.
But I don't think your script shows real performance.

I updated your patch, and I saw small improvement on 512K and significant improvement on 1M.

----------
Added file: https://bugs.python.org/file48816/benchjoin2.py

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

From report at bugs.python.org  Thu Jan  2 00:46:34 2020
From: report at bugs.python.org (Andre Burgaud)
Date: Thu, 02 Jan 2020 05:46:34 +0000
Subject: [issue39187] urllib.robotparser does not respect the longest match
 for the rule
In-Reply-To: <1577938445.91.0.743054392693.issue39187@roundup.psfhosted.org>
Message-ID: <1577943994.16.0.787402544986.issue39187@roundup.psfhosted.org>


Andre Burgaud <andre.burgaud at gmail.com> added the comment:

During testing identified a related issue that is fixed by the same sort function implemented to address the longest match rule.

This related problem also addressed by this change takes into account the situation when 2 equivalent rules (same path for allow and disallow) are found in the robotstxt. In such a situation allow should be used: https://tools.ietf.org/html/draft-koster-rep-00#section-2.2.2

----------

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

From report at bugs.python.org  Thu Jan  2 03:36:56 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 02 Jan 2020 08:36:56 +0000
Subject: [issue35457] robotparser reads empty robots.txt file as "all denied"
In-Reply-To: <1544520647.95.0.788709270274.issue35457@psf.upfronthosting.co.za>
Message-ID: <1577954216.19.0.0622182140321.issue35457@roundup.psfhosted.org>


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

There is a behavior change. parse() sets the modified time and unless the modified time is set the can_fetch method returns false. In Python 2 the parse method was called only when the file is non-empty [0] but in Python 3 it's always called though the file is empty [1] . The change was done with 1afc1696167547a5fa101c53e5a3ab4717f8852c to always read parse and then in 122541beceeccce4ef8a9bf739c727ccdcbf2f28 modified function was always called during parse thus setting the modified_time to return True from can_fetch in the end.

I think the behavior of robotparser for empty file was undefined allowing these changes and it will be good to have a test for this behavior.

[0] https://github.com/python/cpython/blob/f82e59ac4020a64c262a925230a8eb190b652e87/Lib/robotparser.py#L66-L67
[1] https://github.com/python/cpython/blob/149175c6dfc8455023e4335575f3fe3d606729f9/Lib/urllib/robotparser.py#L69-L70

----------
nosy: +berker.peksag, xtreak

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

From report at bugs.python.org  Thu Jan  2 03:42:25 2020
From: report at bugs.python.org (Naveen Durai)
Date: Thu, 02 Jan 2020 08:42:25 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1577954545.58.0.51401442034.issue39168@roundup.psfhosted.org>


Change by Naveen Durai <naveendurai19 at gmail.com>:


----------
nosy: +Naveen Durai

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

From report at bugs.python.org  Thu Jan  2 04:00:56 2020
From: report at bugs.python.org (Alexander Hirner)
Date: Thu, 02 Jan 2020 09:00:56 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1577955656.52.0.68523140358.issue39134@roundup.psfhosted.org>


Alexander Hirner <a.hirner at gmail.com> added the comment:

This results in E(x=None).

I'd need to look into that to understand why.

----------
Added file: https://bugs.python.org/file48817/dc2_repro.py

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

From report at bugs.python.org  Thu Jan  2 05:44:44 2020
From: report at bugs.python.org (Kevin Schlossser)
Date: Thu, 02 Jan 2020 10:44:44 +0000
Subject: [issue39188] recent change when passing a Union to a function
Message-ID: <1577961884.08.0.520696540473.issue39188@roundup.psfhosted.org>


New submission from Kevin Schlossser <kevin.g.schlosser at gmail.com>:

OK so There was a change made to fix issue 26628. Something was forgotten about.. On Windows there is the VARIANT Union which gets used all over the Windows API. This change is going to really break a lot of peoples code and there are no code examples of what needs to be done to fix the now broken ctypes, what needs to be done instead of passing a Union? what new structure has been made that Windows is going to se as a Union? 
That is a huge change to make with no kind of notice that it was going to be done. Now I know it is publicly visible on your issue tracker, but come on now the issue was made 4 years ago and then all of a sudden out of no where boom broken software.. Now If that issue was a major issue and it was causing all kinds of grief I would think that it 
A. would have been fixed sooner... and 
B. there would have been more then a handful of people where the original "bug" caused a problem. 

I am wondering if maybe this bug is a NIX issue. there are simply way to many programs out that are running on Windows and Unions are being passed all the time in functions and no problems are occurring. If there were problems with it in Windows you would have 1000's of reports of crashing from this problem. 

A change like that should be posted on the Python website before it gets made so that all possible repercussions can be looked at.

----------
components: ctypes
messages: 359187
nosy: Kevin Schlossser
priority: normal
severity: normal
status: open
title: recent change when passing a Union to a function
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Jan  2 05:55:28 2020
From: report at bugs.python.org (Bahram Aghaei)
Date: Thu, 02 Jan 2020 10:55:28 +0000
Subject: [issue39189] Use io.DEFAULT_BUFFER_SIZE for filecmp BUFSIZE variable
Message-ID: <1577962528.13.0.543315983881.issue39189@roundup.psfhosted.org>


New submission from Bahram Aghaei <aghaee.bahram at gmail.com>:

Hello there,

I was reading the `filecmp` module and I noticed that it defined the BUFSIZE manually, I think it's better to stick to the io.DEFAULT_BUFFER_SIZE variable for both consistency and easy to maintain in the future.


Cheers,

----------
components: Library (Lib)
messages: 359188
nosy: Bahram Aghaei
priority: normal
pull_requests: 17229
severity: normal
status: open
title: Use io.DEFAULT_BUFFER_SIZE for filecmp BUFSIZE variable
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Jan  2 06:06:00 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 02 Jan 2020 11:06:00 +0000
Subject: [issue16399] argparse: append action with default list adds to list
 instead of overriding
In-Reply-To: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za>
Message-ID: <1577963160.38.0.916034419102.issue16399@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Jan  2 06:20:05 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 02 Jan 2020 11:20:05 +0000
Subject: [issue39173] _AttributeHolder of argparse should support the sort
 function or not?
In-Reply-To: <1577805833.81.0.166775558073.issue39173@roundup.psfhosted.org>
Message-ID: <1577964005.19.0.0866374858089.issue39173@roundup.psfhosted.org>


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

1)>You'd need to elaborate on that. I've been using argparse for years and never once had presentational aspects affected by work. So, again, what is the actual use case for this?
  _AttributeHolder_ has sorted the args in `_get_kwargs()` and the offspring class override this function. So you have accepted this default behavior(do not use sorted attributes).
2)some guys have discussed this question in stackoverflow, such as: https://stackoverflow.com/questions/12268602/sort-argparse-help-alphabetically
3)This bpo stay in discussion stage and receive everyone's opinion ;)

----------

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

From report at bugs.python.org  Thu Jan  2 06:22:33 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 02 Jan 2020 11:22:33 +0000
Subject: [issue16399] argparse: append action with default list adds to list
 instead of overriding
In-Reply-To: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za>
Message-ID: <1577964153.05.0.282597070225.issue16399@roundup.psfhosted.org>


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

I update the doc of argparse and think this bpo could be closed when PR merged.

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

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

From report at bugs.python.org  Thu Jan  2 06:36:57 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Jan 2020 11:36:57 +0000
Subject: [issue39166] Python 3.9.0a2 changed how "async for" traces its final
 iteration
In-Reply-To: <1577712159.27.0.774322517863.issue39166@roundup.psfhosted.org>
Message-ID: <1577965017.66.0.289677014741.issue39166@roundup.psfhosted.org>


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

Can you check if this is fixed with the changes in:

https://github.com/python/cpython/pull/17769

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

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

From report at bugs.python.org  Thu Jan  2 06:38:55 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Jan 2020 11:38:55 +0000
Subject: [issue39114] Python 3.9.0a2 changed how finally/return is traced
In-Reply-To: <1576935645.82.0.331239443144.issue39114@roundup.psfhosted.org>
Message-ID: <1577965135.32.0.938988911323.issue39114@roundup.psfhosted.org>


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


New changeset 04ec7a1f7a5b92187a73cd02670958444c6f2220 by Pablo Galindo in branch 'master':
bpo-39114: Fix tracing of except handlers with name binding (GH-17769)
https://github.com/python/cpython/commit/04ec7a1f7a5b92187a73cd02670958444c6f2220


----------

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

From report at bugs.python.org  Thu Jan  2 07:13:42 2020
From: report at bugs.python.org (=?utf-8?q?Nguy=E1=BB=85n_Gia_Phong?=)
Date: Thu, 02 Jan 2020 12:13:42 +0000
Subject: [issue39125] Type signature of @property not shown in help()
In-Reply-To: <1577115600.68.0.0436692507171.issue39125@roundup.psfhosted.org>
Message-ID: <1577967222.74.0.209715428227.issue39125@roundup.psfhosted.org>


Change by Nguy?n Gia Phong <vn.mcsinyx at gmail.com>:


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

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

From report at bugs.python.org  Thu Jan  2 07:17:19 2020
From: report at bugs.python.org (Bruce Merry)
Date: Thu, 02 Jan 2020 12:17:19 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1577967439.05.0.998044310457.issue36051@roundup.psfhosted.org>


Bruce Merry <bmerry at gmail.com> added the comment:

I'm realising that the benchmark makes it difficult to see what's going on because it doesn't separate overhead costs (slowdowns because releasing/acquiring the GIL is not free, particularly when contended) from cache effects (slowdowns due to parallel threads creating more cache pressure than threads that take turns). inada.naoki's version of the benchmark is better here because it uses the same input data for all the threads, but the output data will still be different in each thread.

For example, on my system I see a big drop in speedup (although I still get speedup) with the new benchmark once the buffer size gets to 2MB per thread, which is not surprising with an 8MB L3 cache.

My feeling is that we should try to ignore cache effects when picking a threshold, because we can't predict them generically (they'll vary by workload, thread count, CPU etc) whereas users can benchmark specific use cases to decide whether multithreading gives them a benefit. If the threshold is too low then users can always choose not to use multi-threading (and in general one doesn't expect much from it in Python) but if the threshold is too high then users have no recourse. That being said, 65536 does still seem a bit low based on the results available.

I'll try to write a variant of the benchmark in which other threads just spin in Python without creating memory pressure to see if that gives a different picture. I'll also run the benchmark on a server CPU when I'm back at work.

----------

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

From report at bugs.python.org  Thu Jan  2 07:26:53 2020
From: report at bugs.python.org (=?utf-8?q?Sindri_Gu=C3=B0mundsson?=)
Date: Thu, 02 Jan 2020 12:26:53 +0000
Subject: [issue39190] _result_handler dies on raised exceptions
 [multiprocessing]
Message-ID: <1577968013.94.0.930637470909.issue39190@roundup.psfhosted.org>


New submission from Sindri Gu?mundsson <sindrigudmundsson at gmail.com>:

Raising an Exception in a callback handler of apply_async and/or map_async will kill the _result_handler thread. This causes unexpected behavior as all subsequent callbacks won't be called and worse, pool.join will deadlock.

The documentation states that callbacks should return immediately but it does not warn the user against raising an exception.

Attached are steps to reproduce.

----------
components: Library (Lib)
files: test_pool_error.py
messages: 359194
nosy: Sindri Gu?mundsson
priority: normal
severity: normal
status: open
title: _result_handler dies on raised exceptions [multiprocessing]
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48818/test_pool_error.py

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

From report at bugs.python.org  Thu Jan  2 07:33:40 2020
From: report at bugs.python.org (=?utf-8?q?Sindri_Gu=C3=B0mundsson?=)
Date: Thu, 02 Jan 2020 12:33:40 +0000
Subject: [issue39190] _result_handler dies on raised exceptions
 [multiprocessing]
In-Reply-To: <1577968013.94.0.930637470909.issue39190@roundup.psfhosted.org>
Message-ID: <1577968420.85.0.309128198901.issue39190@roundup.psfhosted.org>


Change by Sindri Gu?mundsson <sindrigudmundsson at gmail.com>:


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

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

From report at bugs.python.org  Thu Jan  2 07:52:12 2020
From: report at bugs.python.org (Giovanni Lombardo)
Date: Thu, 02 Jan 2020 12:52:12 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1577969532.28.0.946126290653.issue39152@roundup.psfhosted.org>


Giovanni Lombardo <g.lombardo at protonmail.com> added the comment:

I've modified the `Scale.configure` implementation as follows:

```
   def configure(self, cnf=None, **kw):
        """Modify or query scale options.

        Setting a value for any of the "from", "from_" or "to" options
        generates a <<RangeChanged>> event."""
        if cnf:
            kw.update(cnf)
        retval = Widget.configure(self, **kw)
        if any(['from' in kw, 'from_' in kw, 'to' in kw]):
            self.event_generate('<<RangeChanged>>')
        return retval
```

It works as expected for my project, but I don't have regression tests or exahustive code checking in place to verify it behaves correctly for all use cases. How can we manage to perform those tests?

----------

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

From report at bugs.python.org  Thu Jan  2 08:34:18 2020
From: report at bugs.python.org (Kaveshnikov Denis)
Date: Thu, 02 Jan 2020 13:34:18 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
Message-ID: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>


New submission from Kaveshnikov Denis <kaveshnikov.denis at hotmail.com>:

Hi, I found that if to call run_until_complete() in the task while the event loop will be running, a coroutine sent to run_until_complete() will be performed despite the exception raised from run_until_complete().
It seems to me, it would be better to cancel such a coroutine or just do nothing with it.

----------
components: asyncio
files: test_event_loop.py
messages: 359196
nosy: asvetlov, dkaveshnikov, yselivanov
priority: normal
severity: normal
status: open
title: Coroutine is awaited despite an exception in run_until_complete()
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48819/test_event_loop.py

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

From report at bugs.python.org  Thu Jan  2 08:57:29 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 02 Jan 2020 13:57:29 +0000
Subject: [issue39192] relationlist module
Message-ID: <1577973449.68.0.593024649325.issue39192@roundup.psfhosted.org>


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

I've written a handy tool--RelationList. This type can easily create relations between elements in lists.

----------
components: Demos and Tools
files: relationlist.py
messages: 359197
nosy: asvetlov, dkaveshnikov, wyz23x2, yselivanov
priority: normal
severity: normal
status: open
title: relationlist module
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file48820/relationlist.py

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

From report at bugs.python.org  Thu Jan  2 09:06:06 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 02 Jan 2020 14:06:06 +0000
Subject: [issue39192] relationlist module
In-Reply-To: <1577973449.68.0.593024649325.issue39192@roundup.psfhosted.org>
Message-ID: <1577973966.88.0.462261467444.issue39192@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
components:  -Demos and Tools
versions: +Python 3.9 -Python 3.8

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

From report at bugs.python.org  Thu Jan  2 09:07:17 2020
From: report at bugs.python.org (wyz23x2)
Date: Thu, 02 Jan 2020 14:07:17 +0000
Subject: [issue39192] relationlist module
In-Reply-To: <1577973449.68.0.593024649325.issue39192@roundup.psfhosted.org>
Message-ID: <1577974037.7.0.10073650217.issue39192@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

I've written a handy tool--RelationList. This type can easily create relations between elements in lists.

----------
Added file: https://bugs.python.org/file48821/relationlist.py

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

From report at bugs.python.org  Thu Jan  2 09:55:57 2020
From: report at bugs.python.org (ggbang)
Date: Thu, 02 Jan 2020 14:55:57 +0000
Subject: [issue39193] Out-of-bound write in ceval.c:_PyEval_EvalFrameDefault
Message-ID: <1577976957.26.0.433242127529.issue39193@roundup.psfhosted.org>


New submission from ggbang <dg_lsn at hotmail.com>:

python version:
Python 3.9.0a2 (default, Dec 25 2019, 20:42:47) 
[GCC 7.5.0] on linux

crash log:
``` bash
???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? code:x86:64 ????
   0x5555555afb88 <_PyEval_EvalFrameDefault+4056> mov    rdx, QWORD PTR [rsi+rdx*8+0x18]
   0x5555555afb8d <_PyEval_EvalFrameDefault+4061> add    QWORD PTR [rdx], 0x1
   0x5555555afb91 <_PyEval_EvalFrameDefault+4065> test   eax, eax
 ? 0x5555555afb93 <_PyEval_EvalFrameDefault+4067> mov    QWORD PTR [rcx], rdx
   0x5555555afb96 <_PyEval_EvalFrameDefault+4070> jne    0x5555555af226 <_PyEval_EvalFrameDefault+1654>
   0x5555555afb9c <_PyEval_EvalFrameDefault+4076> mov    rdx, r12
   0x5555555afb9f <_PyEval_EvalFrameDefault+4079> sub    rdx, QWORD PTR [rsp+0x8]
   0x5555555afba4 <_PyEval_EvalFrameDefault+4084> add    r12, 0x2
   0x5555555afba8 <_PyEval_EvalFrameDefault+4088> mov    DWORD PTR [rbx+0x68], edx
????????????????????????????????????????????????????????????????????????????????????????????????????????????? source:Python/ceval.c+1352 ????
   1347	 
   1348	         case TARGET(LOAD_CONST): {
   1349	             PREDICTED(LOAD_CONST);
   1350	             PyObject *value = GETITEM(consts, oparg);
   1351	             Py_INCREF(value);
 ? 1352	             PUSH(value);
   1353	             FAST_DISPATCH();
   1354	         }
   1355	 
   1356	         case TARGET(STORE_FAST): {
   1357	             PREDICTED(STORE_FAST);
???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? threads ????
[#0] Id 1, Name: "python", stopped, reason: SIGSEGV
?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? trace ????
[#0] 0x5555555afb93 ? _PyEval_EvalFrameDefault(f=<optimized out>, throwflag=<optimized out>)
[#1] 0x55555568ad59 ? _PyEval_EvalFrame(tstate=0x555555b237b0, throwflag=0x0, f=0x7ffff7eee440)
[#2] 0x55555568ad59 ? _PyEval_EvalCode(tstate=0x555555b237b0, _co=0x7ffff7ebdd40, globals=0x7ffff7f12480, locals=0x7ffff7f12480, args=0x0, argcount=0x0, kwnames=0x0, kwargs=0x0, kwcount=0x0, kwstep=0x2, defs=0x0, defcount=0x0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0)
[#3] 0x55555568b0c6 ? _PyEval_EvalCodeWithName(qualname=0x0, name=0x0, closure=0x0, kwdefs=0x0, defcount=0x0, defs=0x0, kwstep=0x2, kwcount=0x0, kwargs=0x0, kwnames=0x0, argcount=0x0, args=0x0, locals=0x7ffff7f12480, globals=0x7ffff7f12480, _co=0x7ffff7ebdd40)
[#4] 0x55555568b0c6 ? PyEval_EvalCodeEx(closure=0x0, kwdefs=0x0, defcount=0x0, defs=0x0, kwcount=0x0, kws=0x0, argcount=0x0, args=0x0, locals=0x7ffff7f12480, globals=0x7ffff7f12480, _co=0x7ffff7ebdd40)
[#5] 0x55555568b0c6 ? PyEval_EvalCode(co=0x7ffff7ebdd40, globals=0x7ffff7f12480, locals=0x7ffff7f12480)
[#6] 0x5555556d6f1e ? run_eval_code_obj(locals=0x7ffff7f12480, globals=0x7ffff7f12480, co=0x7ffff7ebdd40)
[#7] 0x5555556d6f1e ? run_pyc_file(filename=<optimized out>, flags=0x7fffffffdc68, locals=0x7ffff7f12480, globals=0x7ffff7f12480, fp=0x555555b85360)
[#8] 0x5555556d6f1e ? PyRun_SimpleFileExFlags(flags=<optimized out>, closeit=<optimized out>, filename=<optimized out>, fp=<optimized out>)
[#9] 0x5555556d6f1e ? PyRun_SimpleFileEx(f=<optimized out>, p=<optimized out>, c=<optimized out>)
?????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
_PyEval_EvalFrameDefault (f=<optimized out>, throwflag=<optimized out>) at Python/ceval.c:1352
1352	            PUSH(value);
gef?  exploitable
Description: Access violation on destination operand
Short description: DestAv (8/22)
Hash: f01ce56ffe2792b45d9959e69a1ae15d.6dcf66201de3c2adc2e25e04dbdb55e8
Exploitability Classification: EXPLOITABLE
Explanation: The target crashed on an access violation at an address matching the destination operand of the instruction. This likely indicates a write access violation, which means the attacker may control the write address and/or value.
Other tags: AccessViolation (21/22)
```

----------
components: Interpreter Core
files: c1
messages: 359199
nosy: ggbang
priority: normal
severity: normal
status: open
title: Out-of-bound write in ceval.c:_PyEval_EvalFrameDefault
type: security
versions: Python 3.9
Added file: https://bugs.python.org/file48822/c1

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

From report at bugs.python.org  Thu Jan  2 09:56:42 2020
From: report at bugs.python.org (ggbang)
Date: Thu, 02 Jan 2020 14:56:42 +0000
Subject: [issue39193] Out-of-bound write in ceval.c:_PyEval_EvalFrameDefault
In-Reply-To: <1577976957.26.0.433242127529.issue39193@roundup.psfhosted.org>
Message-ID: <1577977002.51.0.951116578227.issue39193@roundup.psfhosted.org>


Change by ggbang <dg_lsn at hotmail.com>:


Added file: https://bugs.python.org/file48823/crashc1.md

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

From report at bugs.python.org  Thu Jan  2 10:09:12 2020
From: report at bugs.python.org (Jonathan Martin)
Date: Thu, 02 Jan 2020 15:09:12 +0000
Subject: [issue39194] asyncio.open_connection returns a closed client when
 server fails to authenticate client certificate
Message-ID: <1577977752.03.0.200427966409.issue39194@roundup.psfhosted.org>


New submission from Jonathan Martin <jonathan.martin at marss.com>:

I'm trying to use SSL to validate clients connecting a an asyncio socket server by specifying CERT_REQUIRED and giving a `cafile` containing the client certificate to allow. client and server code attached.

Certificates are generated with:

openssl req -x509 -newkey rsa:2048 -keyout client.key -nodes -out client.cert -sha256 -days 100

openssl req -x509 -newkey rsa:2048 -keyout server.key -nodes -out server.cert -sha256 -days 100

Observed behavior with python 3.7.5 and openSSL 1.1.1d
------------------------------------------------------

When the client tries to connect without specifying a certificate, the call to asyncio.open_connection succeeds, but the received socket is closed right away, or to be more exact an EOF is received.

Observed behavior with python 3.7.4 and openSSL 1.0.2t
------------------------------------------------------

When the client tries to connect without specifying a certificate, the call to asyncio.open_connection fails.

Expected behavior
-----------------

I'm not sure which behavior is to be considered the expected one, although I would prefer to connection to fail directly instead of returning a dead client. Wouldn't it be better to have only one behavior?

Note that when disabling TLSv1.3, the connection does fail to open:
ctx.maximum_version = ssl.TLSVersion.TLSv1_2

This can be reproduces on all latest releases of 3.6, 3.7, and 3.8 (which all have openssl 1.1.1d in my case)

----------
assignee: christian.heimes
components: SSL, asyncio
files: example_code.py
messages: 359200
nosy: Jonathan Martin, asvetlov, christian.heimes, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.open_connection returns a closed client when server fails to authenticate client certificate
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48824/example_code.py

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

From report at bugs.python.org  Thu Jan  2 10:25:25 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 02 Jan 2020 15:25:25 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1577978725.54.0.929202323279.issue39191@roundup.psfhosted.org>


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

Agree, this is a bug.

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

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

From report at bugs.python.org  Thu Jan  2 10:29:45 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 02 Jan 2020 15:29:45 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1577978985.37.0.416208292373.issue39191@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Jan  2 10:45:55 2020
From: report at bugs.python.org (Andre Burgaud)
Date: Thu, 02 Jan 2020 15:45:55 +0000
Subject: [issue35457] robotparser reads empty robots.txt file as "all denied"
In-Reply-To: <1544520647.95.0.788709270274.issue35457@psf.upfronthosting.co.za>
Message-ID: <1577979955.45.0.577282770452.issue35457@roundup.psfhosted.org>


Andre Burgaud <andre.burgaud at gmail.com> added the comment:

Thanks @xtreak for providing some clarification on this behavior! I can write some tests to cover this behavior, assuming that we agree that an empty file means "unlimited access". This was worded as such in the old internet draft from 1996 (section 3.2.1 in https://www.robotstxt.org/norobots-rfc.txt). The current draft is more ambiguous with "If no group satisfies either condition, or no groups are present at all, no rules apply." https://tools.ietf.org/html/draft-koster-rep-00#section-2.2.1

https://www.robotstxt.org/robotstxt.html clearly states that an empty file gives full access, but I'm getting lost in figuring out which is the official spec at the moment :-)

----------

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

From report at bugs.python.org  Thu Jan  2 10:52:52 2020
From: report at bugs.python.org (SilentGhost)
Date: Thu, 02 Jan 2020 15:52:52 +0000
Subject: [issue39173] _AttributeHolder of argparse should support the sort
 function or not?
In-Reply-To: <1577805833.81.0.166775558073.issue39173@roundup.psfhosted.org>
Message-ID: <1577980372.89.0.277342858446.issue39173@roundup.psfhosted.org>


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

The answer to the SO question seems rather complete to me and the only thing to be done on our side would be to document Formatter class and perhaps provide example implementation for sorting formatter. Assuming Raymond goes ahead with #39058 I'm still not sure who the proposed additional argument would be interesting to.

----------

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

From report at bugs.python.org  Thu Jan  2 12:21:52 2020
From: report at bugs.python.org (Batuhan)
Date: Thu, 02 Jan 2020 17:21:52 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1577985712.16.0.38060209441.issue38870@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17232
pull_request: https://github.com/python/cpython/pull/17797

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

From report at bugs.python.org  Thu Jan  2 12:22:00 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 02 Jan 2020 17:22:00 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1577985720.57.0.879857132157.issue39134@roundup.psfhosted.org>


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

No doubt because your getter returns None.

----------

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

From report at bugs.python.org  Thu Jan  2 12:25:19 2020
From: report at bugs.python.org (Batuhan)
Date: Thu, 02 Jan 2020 17:25:19 +0000
Subject: [issue15273] Remove unnecessarily random behavior from test_unparse.py
In-Reply-To: <1341664153.44.0.16452834514.issue15273@psf.upfronthosting.co.za>
Message-ID: <1577985919.38.0.0842379638265.issue15273@roundup.psfhosted.org>


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

I guess this resolved with PR 17738

----------

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

From report at bugs.python.org  Thu Jan  2 12:33:38 2020
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 02 Jan 2020 17:33:38 +0000
Subject: [issue39186] Windows installer instructions refer to mercurial
In-Reply-To: <1577931824.82.0.916015771448.issue39186@roundup.psfhosted.org>
Message-ID: <1577986418.13.0.428022089864.issue39186@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9

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

From report at bugs.python.org  Thu Jan  2 12:45:55 2020
From: report at bugs.python.org (Batuhan)
Date: Thu, 02 Jan 2020 17:45:55 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1577987155.89.0.809198235087.issue38870@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17233
pull_request: https://github.com/python/cpython/pull/17798

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

From report at bugs.python.org  Thu Jan  2 13:20:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Jan 2020 18:20:33 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1577989233.09.0.786251491925.issue38870@roundup.psfhosted.org>


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


New changeset 7b35bef9787cd80ed1e12124f759b4be03c849db by Pablo Galindo (Batuhan Ta?kaya) in branch 'master':
bpo-38870: Throw ValueError on invalid yield from usage (GH-17798)
https://github.com/python/cpython/commit/7b35bef9787cd80ed1e12124f759b4be03c849db


----------

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

From report at bugs.python.org  Thu Jan  2 13:22:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Jan 2020 18:22:22 +0000
Subject: [issue15273] Remove unnecessarily random behavior from test_unparse.py
In-Reply-To: <1341664153.44.0.16452834514.issue15273@psf.upfronthosting.co.za>
Message-ID: <1577989342.1.0.829377200953.issue15273@roundup.psfhosted.org>


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

> I guess this resolved with PR 17738

Yup. Closing as per PR 17738.

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

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

From report at bugs.python.org  Thu Jan  2 13:36:10 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Jan 2020 18:36:10 +0000
Subject: [issue39192] relationlist module
In-Reply-To: <1577973449.68.0.593024649325.issue39192@roundup.psfhosted.org>
Message-ID: <1577990170.68.0.26615693001.issue39192@roundup.psfhosted.org>


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

Thanks for the suggestion. If you want to get this added to core Python, there's a bit more you'll need to do here: first, you'd need to persuade the core developers that this functionality is needed. Some real-world motivating examples would help a lot with this. Second, if there's widespread acceptance of the idea, it would be useful to have an implementation that includes accompanying tests and documentation. (Especially documentation: it's not at all clear to me just looking at the code what exact problem it's solving.)

In this case, I'd suggest taking this to the python-ideas mailing list for further discussion (https://mail.python.org/mailman3/lists/python-ideas.python.org/).

You can also take a look at this part of the developer guide for more guidelines on adding new functionality to Python: https://devguide.python.org/stdlibchanges/

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

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

From report at bugs.python.org  Thu Jan  2 13:59:30 2020
From: report at bugs.python.org (Recursing)
Date: Thu, 02 Jan 2020 18:59:30 +0000
Subject: [issue39195] re._compile should check if the argument is a compiled
 pattern before checking cache and flags
Message-ID: <1577991570.36.0.292103009672.issue39195@roundup.psfhosted.org>


New submission from Recursing <buonanno.lorenzo at gmail.com>:

In the re module, re._compile gets called when using most re methods.
In my use case (which I think is not rare) I have a small number of compiled patterns that I have to match against a large number of short strings

profiling showed that half of the total runtime was still spent in re._compile, checking for the type of the flags and trying to get the pattern in a cache

Example code that exhibits this behavior:

import re

pattern = re.compile("spam")
string = "Monty pythons"
for _ in range(1000000):
    re.search(pattern, string)

----------
components: Library (Lib)
messages: 359210
nosy: Recursing
priority: normal
severity: normal
status: open
title: re._compile should check if the argument is a compiled pattern before checking cache and flags
type: performance
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Jan  2 14:01:14 2020
From: report at bugs.python.org (Recursing)
Date: Thu, 02 Jan 2020 19:01:14 +0000
Subject: [issue39195] re._compile should check if the argument is a compiled
 pattern before checking cache and flags
In-Reply-To: <1577991570.36.0.292103009672.issue39195@roundup.psfhosted.org>
Message-ID: <1577991674.83.0.674247555236.issue39195@roundup.psfhosted.org>


Change by Recursing <buonanno.lorenzo at gmail.com>:


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

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

From report at bugs.python.org  Thu Jan  2 14:01:57 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 02 Jan 2020 19:01:57 +0000
Subject: [issue39192] relationlist module
In-Reply-To: <1577973449.68.0.593024649325.issue39192@roundup.psfhosted.org>
Message-ID: <1577991717.46.0.607392156099.issue39192@roundup.psfhosted.org>


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

I'm going to close this here. The issue can be re-opened if there's consensus on python-ideas or elsewhere that it's useful.

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

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

From report at bugs.python.org  Thu Jan  2 14:10:58 2020
From: report at bugs.python.org (Joe Gordon)
Date: Thu, 02 Jan 2020 19:10:58 +0000
Subject: [issue39196] json fails to encode dictionary view types
Message-ID: <1577992258.0.0.878269321128.issue39196@roundup.psfhosted.org>


New submission from Joe Gordon <joe.gordon0 at gmail.com>:

Python 3 fails to encode dictionary view objects. Assuming this is an expected behavior, what is the thinking behind it? I was unable to find any documentation around this.

> import json; json.dumps({}.values())
"TypeError: Object of type dict_values is not JSON serializable"

----------
components: Library (Lib)
messages: 359212
nosy: jogo
priority: normal
severity: normal
status: open
title: json fails to encode dictionary view types
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/issue39196>
_______________________________________

From report at bugs.python.org  Thu Jan  2 14:24:45 2020
From: report at bugs.python.org (Recursing)
Date: Thu, 02 Jan 2020 19:24:45 +0000
Subject: [issue39195] re._compile should check if the argument is a compiled
 pattern before checking cache and flags
In-Reply-To: <1577991570.36.0.292103009672.issue39195@roundup.psfhosted.org>
Message-ID: <1577993085.96.0.348603995362.issue39195@roundup.psfhosted.org>


Recursing <buonanno.lorenzo at gmail.com> added the comment:

I now know that the correct and fastest way to do this is to use pattern.search, but I still think this change would be an improvement

----------

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

From report at bugs.python.org  Thu Jan  2 14:47:42 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Thu, 02 Jan 2020 19:47:42 +0000
Subject: [issue39166] Python 3.9.0a2 changed how "async for" traces its final
 iteration
In-Reply-To: <1577712159.27.0.774322517863.issue39166@roundup.psfhosted.org>
Message-ID: <1577994462.57.0.343119990565.issue39166@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Pablo, thanks, but that PR does not fix this problem.

I'm a little confused: there's a program in this issue to demonstrate the problem.  Can I do something to make it easier for you to use?

----------

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

From report at bugs.python.org  Thu Jan  2 14:51:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Jan 2020 19:51:58 +0000
Subject: [issue39195] re._compile should check if the argument is a compiled
 pattern before checking cache and flags
In-Reply-To: <1577991570.36.0.292103009672.issue39195@roundup.psfhosted.org>
Message-ID: <1577994718.28.0.120171004778.issue39195@roundup.psfhosted.org>


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

PR 17799 improves the performance of an uncommon case at the cost of reducing the performance of a common case. I doubt this is a good change.

If you have a compiled pattern, it is better to use its methods.

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

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

From report at bugs.python.org  Thu Jan  2 14:58:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 02 Jan 2020 19:58:08 +0000
Subject: [issue39196] json fails to encode dictionary view types
In-Reply-To: <1577992258.0.0.878269321128.issue39196@roundup.psfhosted.org>
Message-ID: <1577995088.25.0.881202949799.issue39196@roundup.psfhosted.org>


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

To handle non-standard types you can implement the default() method in the subclass of json.JSONEncoder (https://docs.python.org/3/library/json.html#json.JSONEncoder.default) or pass the corresponding argument to json.JSONEncoder() or json.dumps().

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

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

From report at bugs.python.org  Thu Jan  2 15:07:45 2020
From: report at bugs.python.org (signing_agreement)
Date: Thu, 02 Jan 2020 20:07:45 +0000
Subject: [issue39197] Support the title and description arguments for mutually
 exclusive argument groups
Message-ID: <1577995665.78.0.21290537011.issue39197@roundup.psfhosted.org>


New submission from signing_agreement <kuglasses at gmail.com>:

add_mutually_exclusive_group has one flag, required=False. Yet, regardless of specifying required=True, the help message calls the group "optional arguments". It would be nice to be able to add title and description for mutually exclusive groups.

Right now, programmers can only do changes via
parser._action_groups[1].title = 'mutually exclusive required arguments'

----------
components: Library (Lib)
messages: 359217
nosy: signing_agreement
priority: normal
severity: normal
status: open
title: Support the title and description arguments for mutually exclusive argument groups
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Jan  2 15:10:00 2020
From: report at bugs.python.org (Recursing)
Date: Thu, 02 Jan 2020 20:10:00 +0000
Subject: [issue39195] re._compile should check if the argument is a compiled
 pattern before checking cache and flags
In-Reply-To: <1577991570.36.0.292103009672.issue39195@roundup.psfhosted.org>
Message-ID: <1577995800.6.0.18075554392.issue39195@roundup.psfhosted.org>


Recursing <buonanno.lorenzo at gmail.com> added the comment:

Rereading the documentation it's actually well documented, and I fully agree.

Thanks for your time

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

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

From report at bugs.python.org  Thu Jan  2 15:10:20 2020
From: report at bugs.python.org (Derek Brown)
Date: Thu, 02 Jan 2020 20:10:20 +0000
Subject: [issue39198] Lock may not be released in Logger.isEnabledFor
Message-ID: <1577995820.85.0.483829284775.issue39198@roundup.psfhosted.org>


New submission from Derek Brown <derekbrown at fb.com>:

If an exception were to be thrown in a particular block of code (say, by asyncio timeouts or stopit) within the `isEnabledFor` function of `logging`, the `logging` global lock may not be released appropriately, resulting in deadlock.

----------
components: Library (Lib)
messages: 359219
nosy: derektbrown
priority: normal
severity: normal
status: open
title: Lock may not be released in Logger.isEnabledFor
type: crash
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Jan  2 15:12:13 2020
From: report at bugs.python.org (Derek Brown)
Date: Thu, 02 Jan 2020 20:12:13 +0000
Subject: [issue39198] Lock may not be released in Logger.isEnabledFor
In-Reply-To: <1577995820.85.0.483829284775.issue39198@roundup.psfhosted.org>
Message-ID: <1577995933.92.0.910422738735.issue39198@roundup.psfhosted.org>


Change by Derek Brown <derekbrown at fb.com>:


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

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

From report at bugs.python.org  Thu Jan  2 15:19:01 2020
From: report at bugs.python.org (Derek Brown)
Date: Thu, 02 Jan 2020 20:19:01 +0000
Subject: [issue39198] Lock may not be released in Logger.isEnabledFor
In-Reply-To: <1577995820.85.0.483829284775.issue39198@roundup.psfhosted.org>
Message-ID: <1577996341.83.0.392259506133.issue39198@roundup.psfhosted.org>


Derek Brown <derekbrown at fb.com> added the comment:

PR is here: https://github.com/python/cpython/pull/17689

----------

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

From report at bugs.python.org  Thu Jan  2 16:25:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Jan 2020 21:25:20 +0000
Subject: [issue39166] Python 3.9.0a2 changed how "async for" traces its final
 iteration
In-Reply-To: <1577712159.27.0.774322517863.issue39166@roundup.psfhosted.org>
Message-ID: <1578000320.43.0.248331125139.issue39166@roundup.psfhosted.org>


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

> I'm a little confused: there's a program in this issue to demonstrate the problem.  Can I do something to make it easier for you to use?

Sorry for the confusion, I was asking because at the time of asking I didn't have access to a computer to check myself.

I will investigate tonight as soon as I can get to my computer.

----------

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

From report at bugs.python.org  Thu Jan  2 17:12:00 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 02 Jan 2020 22:12:00 +0000
Subject: [issue34444] Module's __file__ should be absolute always ("." in
 sys.path)
In-Reply-To: <1534784236.56.0.56676864532.issue34444@psf.upfronthosting.co.za>
Message-ID: <1578003120.11.0.357604253691.issue34444@roundup.psfhosted.org>


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

RE: "This could be done when inserting something into `sys.path` maybe then only?" That would require a custom object instead of a standard list for sys.path which could detect insertion and then do the automatic absolute path resolution which as you pointed out will inevitably break things for someone somewhere.

----------

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

From report at bugs.python.org  Thu Jan  2 17:13:44 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 02 Jan 2020 22:13:44 +0000
Subject: [issue30427] isinstance checks in os.path.normcase redundant with
 os.fspath
In-Reply-To: <1495441077.08.0.893428733741.issue30427@psf.upfronthosting.co.za>
Message-ID: <1578003224.74.0.812980389425.issue30427@roundup.psfhosted.org>


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

Yep, it looks like this is fixed, Batuhan. Thanks for letting us know!

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

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

From report at bugs.python.org  Thu Jan  2 17:17:46 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 02 Jan 2020 22:17:46 +0000
Subject: [issue39166] Python 3.9.0a2 changed how "async for" traces its final
 iteration
In-Reply-To: <1577712159.27.0.774322517863.issue39166@roundup.psfhosted.org>
Message-ID: <1578003466.14.0.210662167093.issue39166@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Thu Jan  2 18:23:52 2020
From: report at bugs.python.org (And Clover)
Date: Thu, 02 Jan 2020 23:23:52 +0000
Subject: [issue23434] support encoded filename in Content-Disposition for HTTP
 in cgi.FieldStorage
In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za>
Message-ID: <1578007432.43.0.747332074151.issue23434@roundup.psfhosted.org>


And Clover <and at doxdesk.com> added the comment:

HTTP generally isn't an RFC 822-family standard. Its headers look a lot like it, but they have their own defined syntax that differs in niggling little details. Using mail parsing code for HTTP isn't usually the right thing.

HTTP has always used its own syntax definitions for the headers on the main request/response entities, but it has traditionally partially deferred to RFC 822-family specs for the definitions of structured entity bodies. This is moot, however, as the reality of what browsers support has rarely coincided with those specs.

Nowadays HTML5.2 explicitly defers to RFC 7578 for definition of multipart/form-data headers. (This RFC is a replacement for the vague and broken RFC 2388.) As is to be expected for an HTML5-related spec, RFC 7578 shrugs and documents existing browser behaviour [section 4.2]:

- some browsers do UTF-8
- some browsers do data mangling (IE's %-encoding sadness)
- some browsers might do something else

but it explicitly rules out the solution proposed here:

"The encoding method described in [RFC5987], which would add a 'filename*' parameter to the Content-Disposition header field, MUST NOT be used."

The introductions of both RFC 5987 and RFC 6266 explicitly exclude multipart/form-data headers from their remit.

So in summary:

- we shouldn't do anything
- the situation with submitted filenames will continue to be broken for everyone indefinitely

----------
nosy: +aclover

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

From report at bugs.python.org  Thu Jan  2 20:28:49 2020
From: report at bugs.python.org (Andre Roberge)
Date: Fri, 03 Jan 2020 01:28:49 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1578014929.4.0.187201894781.issue33944@roundup.psfhosted.org>


Change by Andre Roberge <andre.roberge at gmail.com>:


----------
nosy: +aroberge

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

From report at bugs.python.org  Thu Jan  2 21:42:34 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 03 Jan 2020 02:42:34 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1578019354.05.0.979386570877.issue36051@roundup.psfhosted.org>


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

> (slowdowns because releasing/acquiring the GIL is not free, particularly when contended) 

Yes, it's relatively high.  We shouldn't release the GIL only for ~0.5ms.  That's why 1MB~ seems nice threshold.

>  If the threshold is too low then users can always choose not to use multi-threading (and in general one doesn't expect much from it in Python)

I don't like this idea.  We shouldn't force users to change their program from multi threaded to single threaded.  So we need to avoid large performance regression.


> but if the threshold is too high then users have no recourse. That being said, 65536 does still seem a bit low based on the results available.

But they can get the benefit when input is too large. 65536 seems "too low" to me.

----------

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

From report at bugs.python.org  Fri Jan  3 00:21:26 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Jan 2020 05:21:26 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1578028886.43.0.168886392339.issue39158@roundup.psfhosted.org>


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


New changeset 4fcf5c12a37a8d3d8d6303c44c223dbc8d568cfd by Raymond Hettinger in branch 'master':
bpo-39158: ast.literal_eval() doesn't support empty sets (GH-17742)
https://github.com/python/cpython/commit/4fcf5c12a37a8d3d8d6303c44c223dbc8d568cfd


----------

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

From report at bugs.python.org  Fri Jan  3 00:21:37 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 03 Jan 2020 05:21:37 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1578028897.97.0.38867590256.issue39158@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jan  3 00:48:24 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 03 Jan 2020 05:48:24 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1578030504.96.0.77247716382.issue27973@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for the suggestion, David. I have updated the PR 17774 to use temp_support instead of NamedTemporaryFile. Please review this.

----------

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

From report at bugs.python.org  Fri Jan  3 01:40:35 2020
From: report at bugs.python.org (David Bolen)
Date: Fri, 03 Jan 2020 06:40:35 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1578033634.99.0.854066551923.issue27973@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

I'd be happy to test an updated PR 17774 on a Windows builder, but I don't actually see any change yet.  It still appears to hold the earlier NamedTemporaryFile with mode='w' change from a few days ago.

----------

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

From report at bugs.python.org  Fri Jan  3 06:02:52 2020
From: report at bugs.python.org (Rafael Fontenelle)
Date: Fri, 03 Jan 2020 11:02:52 +0000
Subject: [issue39183] Text divided in two strings due to wrong formatting
In-Reply-To: <1577916396.48.0.991932601877.issue39183@roundup.psfhosted.org>
Message-ID: <1578049372.14.0.541306920537.issue39183@roundup.psfhosted.org>


Rafael Fontenelle <rffontenelle at gmail.com> added the comment:

Fix confirmed, closing.

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

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

From report at bugs.python.org  Fri Jan  3 06:14:01 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Jan 2020 11:14:01 +0000
Subject: [issue39193] Out-of-bound write in ceval.c:_PyEval_EvalFrameDefault
In-Reply-To: <1577976957.26.0.433242127529.issue39193@roundup.psfhosted.org>
Message-ID: <1578050041.34.0.41656459964.issue39193@roundup.psfhosted.org>


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

It seems what you're saying is that one can crash Python by crafting deliberately incorrect bytecode.  If so, then I'm afraid it's something we won't consider fixing.

----------
nosy: +pitrou

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

From report at bugs.python.org  Fri Jan  3 06:14:26 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Jan 2020 11:14:26 +0000
Subject: [issue39193] Out-of-bound write in ceval.c:_PyEval_EvalFrameDefault
In-Reply-To: <1577976957.26.0.433242127529.issue39193@roundup.psfhosted.org>
Message-ID: <1578050066.73.0.28569709139.issue39193@roundup.psfhosted.org>


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


----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Fri Jan  3 06:35:33 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 03 Jan 2020 11:35:33 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1578051333.4.0.848125721512.issue27973@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Sorry, I have updated it now: https://github.com/python/cpython/pull/17774

(I had pushed to a different branch earlier and it didn't reflect in my PR)

----------

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

From report at bugs.python.org  Fri Jan  3 06:53:21 2020
From: report at bugs.python.org (ggbang)
Date: Fri, 03 Jan 2020 11:53:21 +0000
Subject: [issue39193] Out-of-bound write in ceval.c:_PyEval_EvalFrameDefault
In-Reply-To: <1577976957.26.0.433242127529.issue39193@roundup.psfhosted.org>
Message-ID: <1578052401.13.0.237527476791.issue39193@roundup.psfhosted.org>


ggbang <dg_lsn at hotmail.com> added the comment:

hello, if a crafting deliberately incorrect bytecode could control the eip of Python interpreter, it's the scope to fix? thx.

----------

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

From report at bugs.python.org  Fri Jan  3 07:16:16 2020
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 03 Jan 2020 12:16:16 +0000
Subject: [issue38532] Missing decrefs in the _ctypes module
In-Reply-To: <1571539888.18.0.273531379045.issue38532@roundup.psfhosted.org>
Message-ID: <1578053776.0.0.467249084809.issue38532@roundup.psfhosted.org>


Thomas Wouters <thomas at python.org> added the comment:


New changeset e02ab59fdffa0bb841182c30ef1355c89578d945 by T. Wouters (Zackery Spytz) in branch 'master':
bpo-38532: Add missing decrefs in PyCFuncPtr_FromDll() (GH-16857)
https://github.com/python/cpython/commit/e02ab59fdffa0bb841182c30ef1355c89578d945


----------
nosy: +twouters

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

From report at bugs.python.org  Fri Jan  3 07:18:10 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 03 Jan 2020 12:18:10 +0000
Subject: [issue38532] Missing decrefs in the _ctypes module
In-Reply-To: <1571539888.18.0.273531379045.issue38532@roundup.psfhosted.org>
Message-ID: <1578053889.99.0.636351381148.issue38532@roundup.psfhosted.org>


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


----------
pull_requests: +17238
pull_request: https://github.com/python/cpython/pull/17811

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

From report at bugs.python.org  Fri Jan  3 07:50:19 2020
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 03 Jan 2020 12:50:19 +0000
Subject: [issue38532] Missing decrefs in the _ctypes module
In-Reply-To: <1571539888.18.0.273531379045.issue38532@roundup.psfhosted.org>
Message-ID: <1578055819.85.0.346339863311.issue38532@roundup.psfhosted.org>


Thomas Wouters <thomas at python.org> added the comment:


New changeset aa3efea9c5f4d25afc3fa4cfd5e6d789943893c9 by T. Wouters (Miss Islington (bot)) in branch '3.8':
bpo-38532: Add missing decrefs in PyCFuncPtr_FromDll() (GH-17811)
https://github.com/python/cpython/commit/aa3efea9c5f4d25afc3fa4cfd5e6d789943893c9


----------

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

From report at bugs.python.org  Fri Jan  3 07:50:36 2020
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 03 Jan 2020 12:50:36 +0000
Subject: [issue38532] Missing decrefs in the _ctypes module
In-Reply-To: <1571539888.18.0.273531379045.issue38532@roundup.psfhosted.org>
Message-ID: <1578055836.86.0.566323958857.issue38532@roundup.psfhosted.org>


Change by Thomas Wouters <thomas at python.org>:


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

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

From report at bugs.python.org  Fri Jan  3 08:05:21 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Jan 2020 13:05:21 +0000
Subject: [issue39199] Improve the AST documentation
Message-ID: <1578056721.05.0.299258437761.issue39199@roundup.psfhosted.org>


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

The AST docs need some love as they can be a bit obscure to someone new to the module. Improvements to be considered in this issue:

* Document all available nodes (as of 3.8 and not deprecated ones). This helps to know what classes to consider when implementing methods for the visitors.

* Add some short practical examples for the visitors: one to query an AST and another to modify it.

----------
assignee: docs at python
components: Documentation
messages: 359235
nosy: docs at python, pablogsal
priority: normal
severity: normal
status: open
title: Improve the AST documentation
versions: Python 3.9

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

From report at bugs.python.org  Fri Jan  3 08:06:29 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Jan 2020 13:06:29 +0000
Subject: [issue39199] Improve the AST documentation
In-Reply-To: <1578056721.05.0.299258437761.issue39199@roundup.psfhosted.org>
Message-ID: <1578056789.3.0.323132059159.issue39199@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jan  3 09:27:51 2020
From: report at bugs.python.org (=?utf-8?q?Julien_F=C3=A9rard?=)
Date: Fri, 03 Jan 2020 14:27:51 +0000
Subject: [issue39200] Inaccurate TypeError message for `range` without argument
Message-ID: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>


New submission from Julien F?rard <julien_ferard at yahoo.fr>:

When passing no argument to `range`, the error message states that (exactly) one argument is expected.

Actual:

    Python 3.9.0a0 (heads/master:d395209653, Jan  3 2020, 11:37:03)
    [GCC 7.4.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> range()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: range expected 1 argument, got 0

Expected message:

    TypeError: range expected at least 1 argument, got 0

(See for instance:

    >>> eval()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: eval expected at least 1 argument, got 0
)

----------
components: Interpreter Core
messages: 359236
nosy: jferard
priority: normal
severity: normal
status: open
title: Inaccurate TypeError message for `range` without argument
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/issue39200>
_______________________________________

From report at bugs.python.org  Fri Jan  3 09:50:29 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Jan 2020 14:50:29 +0000
Subject: [issue39200] Inaccurate TypeError message for `range` without argument
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578063029.94.0.909613764528.issue39200@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jan  3 09:57:13 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 03 Jan 2020 14:57:13 +0000
Subject: [issue39193] Out-of-bound write in ceval.c:_PyEval_EvalFrameDefault
In-Reply-To: <1577976957.26.0.433242127529.issue39193@roundup.psfhosted.org>
Message-ID: <1578063433.92.0.249460499849.issue39193@roundup.psfhosted.org>


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

I don't think so. I'll let other confirm.

----------
nosy: +christian.heimes, vstinner

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

From report at bugs.python.org  Fri Jan  3 10:19:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Jan 2020 15:19:20 +0000
Subject: [issue39193] Out-of-bound write in ceval.c:_PyEval_EvalFrameDefault
In-Reply-To: <1577976957.26.0.433242127529.issue39193@roundup.psfhosted.org>
Message-ID: <1578064760.59.0.291630773219.issue39193@roundup.psfhosted.org>


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

I concur with Antoine, the interpreter does not have any contract around crafting incorrect bytecode and evaluating it (and it will not since by definition the bytecode created by the interpreter is (should) be correct and any extra check in this code path will impact performance notably). 

I also have to say that I struggle to understand how to reproduce this or what is exactly the problem from your text and the files you attach.

Closing this as "not a bug". Feel free to re-open if you think we are missing something else.

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

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

From report at bugs.python.org  Fri Jan  3 10:32:28 2020
From: report at bugs.python.org (Mathias)
Date: Fri, 03 Jan 2020 15:32:28 +0000
Subject: [issue39201] Threading.timer leaks memory in 3.8.0/3.8.1
Message-ID: <1578065548.82.0.563193246076.issue39201@roundup.psfhosted.org>


New submission from Mathias <mane at mmmi.sdu.dk>:

Hi,

I think there is an issue with memory allocating with threading.Timer in 3.8.0/3.8.1.

When I run the attached code in Python 3.7.3 I get a memory consumption of approx. 10 MB. If I run the same code with python 3.8.0 or 3.8.1, it keeps consuming memory (several hundreds of MB). 

I've attached 3 images where I run the attached script under mprof.

By inspect of the output from tracemalloc, I can see that 
/usr/lib/python3.8/threading.py:908 keeps allocating memory.

I have tested this with python 3.8.0 from ubuntu 16.04 repository and python 3.8.1 from source. Both versions suffers from the memory consumption issue.

----------
components: Library (Lib)
files: images_code.tar
messages: 359239
nosy: mneerup
priority: normal
severity: normal
status: open
title: Threading.timer leaks memory in 3.8.0/3.8.1
versions: Python 3.8
Added file: https://bugs.python.org/file48825/images_code.tar

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

From report at bugs.python.org  Fri Jan  3 10:57:33 2020
From: report at bugs.python.org (Matthew Smith)
Date: Fri, 03 Jan 2020 15:57:33 +0000
Subject: [issue39201] Threading.timer leaks memory in 3.8.0/3.8.1
In-Reply-To: <1578065548.82.0.563193246076.issue39201@roundup.psfhosted.org>
Message-ID: <1578067053.96.0.689983339935.issue39201@roundup.psfhosted.org>


Matthew Smith <melkor at orangepalantir.org> added the comment:

This issue also affects me, pyth. I tried it out with various combinations of sleep, and durations of tasks, but what I noticed is that threading_shutdown_locks continues to grow at each iteration.

for i in range(100000):
    for j in range(10):
        timer = threading.Thread(target = callback)
        timer.start()
    time.sleep(1)
    print(len(threading._shutdown_locks))

If I accumulate the Timer/Thread s and join them, then the _shutdown_locks will be cleared.

----------
nosy: +odinsbane

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

From report at bugs.python.org  Fri Jan  3 11:03:10 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 03 Jan 2020 16:03:10 +0000
Subject: [issue39201] Threading.timer leaks memory in 3.8.0/3.8.1
In-Reply-To: <1578065548.82.0.563193246076.issue39201@roundup.psfhosted.org>
Message-ID: <1578067390.78.0.818121781291.issue39201@roundup.psfhosted.org>


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

Please include the script as an attachment or text so that it will be easy to view them. The script as below from the attachment : 

import threading
import time
import tracemalloc

def callback():
    pass

tracemalloc.start()
for i in range(100000):
    snapshot1 = tracemalloc.take_snapshot()
    for i in range(100000):
        timer = threading.Timer(1, callback)
        timer.start()
    snapshot2 = tracemalloc.take_snapshot()
    top_stats = snapshot2.compare_to(snapshot1, 'lineno')
    print("[ Top 10 differences ]")
	
    for stat in top_stats[:10]:
        print(stat)

----------
nosy: +pitrou, xtreak -odinsbane

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

From report at bugs.python.org  Fri Jan  3 11:17:13 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 03 Jan 2020 16:17:13 +0000
Subject: [issue39200] Inaccurate TypeError message for `range` without argument
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578068233.22.0.97643204998.issue39200@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17241
pull_request: https://github.com/python/cpython/pull/17814

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

From report at bugs.python.org  Fri Jan  3 11:19:53 2020
From: report at bugs.python.org (Ilya)
Date: Fri, 03 Jan 2020 16:19:53 +0000
Subject: [issue39202] Python shelve __del__ ignored exception
Message-ID: <1578068393.52.0.269447862583.issue39202@roundup.psfhosted.org>


New submission from Ilya <libbkmz.dev at gmail.com>:

I'm using my own implementation of the memoize by shelve module. In the attachment, there are 2 simple test cases which pass but the console there are a lot of messages like that:

Exception ignored in: <function Shelf.__del__ at 0x0000023202F363A0>
Traceback (most recent call last):
  File "C:\Miniconda2\envs\38_common\lib\shelve.py", line 162, in __del__
    self.close()
  File "C:\Miniconda2\envs\38_common\lib\shelve.py", line 144, in close
    self.sync()
  File "C:\Miniconda2\envs\38_common\lib\shelve.py", line 172, in sync
    self.dict.sync()
  File "C:\Miniconda2\envs\38_common\lib\dbm\dumb.py", line 129, in _commit
    with self._io.open(self._dirfile, 'w', encoding="Latin-1") as f:
PermissionError: [Errno 13] Permission denied: 'C:\\project\\tests\\test_memoize_tmp_t5tai08p\\memoize_test_file.dat.dir'

Exception ignored in: <function _Database.close at 0x0000023202EF9040>
Traceback (most recent call last):
  File "C:\Miniconda2\envs\38_common\lib\dbm\dumb.py", line 274, in close
    self._commit()
  File "C:\Miniconda2\envs\38_common\lib\dbm\dumb.py", line 129, in _commit
    with self._io.open(self._dirfile, 'w', encoding="Latin-1") as f:
PermissionError: [Errno 13] Permission denied: 'C:\\project\\tests\\test_memoize_tmp_t5tai08p\\memoize_test_file.dat.dir'


Basically, the main issue can be explained like that - Python dbm.dumb._Database should maintain self._modified the attribute in the right way(set it to False) after the _commit method. 

Later I will try to make changes in the dbm.dumb module and run Python internal tests for that modification to see any regression, if not will add PR here.

----------
components: Library (Lib)
files: test_python_shelve_issue.py
messages: 359242
nosy: libbkmz
priority: normal
severity: normal
status: open
title: Python shelve __del__ ignored exception
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file48826/test_python_shelve_issue.py

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

From report at bugs.python.org  Fri Jan  3 11:35:08 2020
From: report at bugs.python.org (SilentGhost)
Date: Fri, 03 Jan 2020 16:35:08 +0000
Subject: [issue39200] Inaccurate TypeError message for `range` without argument
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578069308.06.0.649707552308.issue39200@roundup.psfhosted.org>


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


----------
versions:  -Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan  3 11:36:00 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 03 Jan 2020 16:36:00 +0000
Subject: [issue39200] Inaccurate TypeError message for `range` without argument
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578069360.58.0.0659140804941.issue39200@roundup.psfhosted.org>


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

I noticed that min/max builtin function also has the same problem.

For example, PyPy raise TypeError as 
TypeError: max() expects at least one argument.

PR-17814 is an update patch for this.

I suggest changing the title to be "Fix inaccurate TypeError messages when calling with insufficient arguments"

----------
nosy: +corona10, pablogsal
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan  3 11:45:48 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 03 Jan 2020 16:45:48 +0000
Subject: [issue39200] Inaccurate TypeError message for `range` without argument
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578069948.24.0.614275056938.issue39200@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
versions:  -Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jan  3 12:05:50 2020
From: report at bugs.python.org (Adam)
Date: Fri, 03 Jan 2020 17:05:50 +0000
Subject: [issue39201] Threading.timer leaks memory in 3.8.0/3.8.1
In-Reply-To: <1578065548.82.0.563193246076.issue39201@roundup.psfhosted.org>
Message-ID: <1578071149.99.0.889123342844.issue39201@roundup.psfhosted.org>


Adam <adam.jgrant at gmail.com> added the comment:

I filed a bug for this a few weeks ago, and then found another ticket about the same issue before:

https://bugs.python.org/issue37788

My ticket: 
https://bugs.python.org/issue39074

The memory leak was from a change introduced about 6 months ago:

https://github.com/python/cpython/commit/468e5fec8a2f534f1685d59da3ca4fad425c38dd

----------
nosy: +krypticus

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

From report at bugs.python.org  Fri Jan  3 12:28:53 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Jan 2020 17:28:53 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578072533.21.0.192055335002.issue39200@roundup.psfhosted.org>


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


----------
title: Inaccurate TypeError message for `range` without argument -> Fix inaccurate TypeError messages when calling with insufficient arguments

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

From report at bugs.python.org  Fri Jan  3 12:47:16 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Jan 2020 17:47:16 +0000
Subject: [issue39201] Threading.timer leaks memory in 3.8.0/3.8.1
In-Reply-To: <1578065548.82.0.563193246076.issue39201@roundup.psfhosted.org>
Message-ID: <1578073636.75.0.113276137502.issue39201@roundup.psfhosted.org>


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


----------
nosy: +vstinner

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

From report at bugs.python.org  Fri Jan  3 13:33:45 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jan 2020 18:33:45 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578076425.31.0.588228079528.issue29778@roundup.psfhosted.org>


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

> It looks like there has been a regression in the fix for this issue.

You're right. Care to create a pull request to fix it?

----------

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

From report at bugs.python.org  Fri Jan  3 13:40:08 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jan 2020 18:40:08 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1578076808.62.0.915062290109.issue39184@roundup.psfhosted.org>


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

Agreed, we should add events for all of these. They can go into the next 3.8 release.

Ideally, the lowest level operations (typically os module) should raise events. Where it's convenient to also audit operations at a higher level (shutil, subprocess, etc.) then we can do that too, as it provides helpful context for *why* the lower-level operation ran.

Contributions welcome :) I'll likely get to them eventually, but no reason it has to be me adding everything.

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Fri Jan  3 13:48:49 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 03 Jan 2020 18:48:49 +0000
Subject: [issue39182] sys.addaudithook(hook) loops indefinitely on mismatch
 for hook
In-Reply-To: <1577899380.86.0.650724982572.issue39182@roundup.psfhosted.org>
Message-ID: <1578077329.62.0.139589619435.issue39182@roundup.psfhosted.org>


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

I think this is specific to the interactive prompt. Under normal circumstances, any error in calling the hook at the point where an event is being audited (which is immediate when using interactive mode) needs to propagate.

Probably the best way to handle it is to call the hook with a new event indicating it's being added, but before it actually gets put into the list. A hook could then set up a different kind of loop, but it would be much harder to do it by accident.

Perhaps "sys.addaudithook/self" with itself as an argument. We can't just use "sys.addaudithook" in case there are hooks that blindly abort this event (which there are, because I've written them ;) ). But this will at least make sure that the signature is correct and shouldn't send the interactive parser into a loop.

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

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

From report at bugs.python.org  Fri Jan  3 14:02:54 2020
From: report at bugs.python.org (Jason Li)
Date: Fri, 03 Jan 2020 19:02:54 +0000
Subject: [issue39203] python3 time module misses attributes in Mac installers
Message-ID: <1578078174.37.0.442161704111.issue39203@roundup.psfhosted.org>


New submission from Jason Li <likun123mail at gmail.com>:

The issue: AttributeError: module 'time' has no attribute 'clock_gettime'. It probably missed other attributes as well.

The problem only appeared with using installers to install python. While Homebrew installed python does not have the issue.

The issue occurred in versions, 3.7.1, 3.7.3, 3.7.4, 3.8.1, as I observed.

----------
components: macOS
messages: 359248
nosy: jasonli360, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: python3 time module misses attributes in Mac installers
type: compile error
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Jan  3 14:12:25 2020
From: report at bugs.python.org (Cooper Lees)
Date: Fri, 03 Jan 2020 19:12:25 +0000
Subject: [issue39204] Automate adding Type Annotations to Documentation
Message-ID: <1578078745.51.0.848404810387.issue39204@roundup.psfhosted.org>


New submission from Cooper Lees <me at cooperlees.com>:

What are people's thoughts on automating adding type annotations to documentation now that Typeshed is mature and Python 2 is EOL?
(Let us never speak of comment annotations)

----------
components: Library (Lib)
messages: 359249
nosy: cooperlees
priority: normal
severity: normal
status: open
title: Automate adding Type Annotations to Documentation
versions: Python 3.9

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

From report at bugs.python.org  Fri Jan  3 14:12:34 2020
From: report at bugs.python.org (Cooper Lees)
Date: Fri, 03 Jan 2020 19:12:34 +0000
Subject: [issue39204] Automate adding Type Annotations to Documentation
In-Reply-To: <1578078745.51.0.848404810387.issue39204@roundup.psfhosted.org>
Message-ID: <1578078754.44.0.248200218916.issue39204@roundup.psfhosted.org>


Change by Cooper Lees <me at cooperlees.com>:


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

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

From report at bugs.python.org  Fri Jan  3 14:31:46 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Jan 2020 19:31:46 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1578079906.88.0.72127635533.issue39158@roundup.psfhosted.org>


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

The function literal_eval is not safe anymore as the constructor can be intercepted:

>>> import builtins
>>> def evil_code(*args):
...     print("Something evil")
...
>>> builtins.set = evil_code
>>> import ast
>>> ast.literSomething evil

KeyboardInterrupt
>>> ast.literal_eval("set()")
Something evil


I think we should either use {0}.__class__.

Also, the documentation now is wrong as the function does more than evaluate literals or container displays.

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

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

From report at bugs.python.org  Fri Jan  3 14:32:13 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Jan 2020 19:32:13 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1578079933.79.0.748570032813.issue39158@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jan  3 14:32:37 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Jan 2020 19:32:37 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1578079957.37.0.889521096198.issue39158@roundup.psfhosted.org>


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

The function literal_eval is not safe anymore as the constructor can be intercepted:

>>> import builtins
>>> def evil_code(*args):
...     print("Something evil")
...
>>> builtins.set = evil_code
>>> ast.literal_eval("set()")
Something evil


I think we should either use {0}.__class__.

Also, the documentation now is wrong as the function does more than evaluate literals or container displays.

----------

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

From report at bugs.python.org  Fri Jan  3 14:40:29 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Jan 2020 19:40:29 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1578080429.1.0.34389659698.issue39158@roundup.psfhosted.org>


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

> The function literal_eval is not safe anymore as the constructor can be intercepted:

Well, actually it can also be done with any other builtin via the same trick, so this is no different but is only slightly more obvious that it can be done.

I still find a bit weird that the documentation says "literal or container display" but 'set' is neither.

----------

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

From report at bugs.python.org  Fri Jan  3 14:58:16 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 03 Jan 2020 19:58:16 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1578081496.66.0.160476676767.issue39158@roundup.psfhosted.org>


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

I am re-closing the issue as I don't think is worth complicating the docs for this edge case and the security concern is non existent.

Apologies for the noise. If someone feels strongly about the documentation, they can reopen the issue.

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

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

From report at bugs.python.org  Fri Jan  3 15:05:45 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Jan 2020 20:05:45 +0000
Subject: [issue39203] python3 time module misses attributes in Mac installers
In-Reply-To: <1578078174.37.0.442161704111.issue39203@roundup.psfhosted.org>
Message-ID: <1578081945.5.0.150407585048.issue39203@roundup.psfhosted.org>


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

This is a duplicate of Issue34597.

The Pythons provided by the python.org macOS installers are built to run on a range of operating system versions.  The current practice is to build installers that work on any macOS version from 10.9 on.  To safely provide that functionality, the installers are built using a 10.9 ABI.  As noted in the time module documentation, "Although this module is always available, not all functions are available on all platforms."  And, as noted in

   man 3 clock_gettime 

For current macOS releases: "These functions first appeared in Mac OSX 10.12".

So since those functions are not available in macOS 10.9, they are not available in the current python.org macOS Pythons.  There are some other examples of this.

To remove this restriction and still allow builds that support a range of versions, we would need to identify the system interfaces that have been added in new releases and then add code to use weak linking to test at runtime to gracefully handle missing interfaces, rather than segfaulting.  It would be desirable to support that but it's a fair amount of work including adding tests and no one has volunteered to do that work - yet.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Python needs to check existence of functions at runtime for targeting older macOS platforms
type: compile error -> 

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

From report at bugs.python.org  Fri Jan  3 15:19:48 2020
From: report at bugs.python.org (joony kohe)
Date: Fri, 03 Jan 2020 20:19:48 +0000
Subject: [issue14132] SEO Services Development & PHP development
In-Reply-To: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za>
Message-ID: <1578082788.87.0.227858760431.issue14132@roundup.psfhosted.org>


joony kohe <kbjoon2426 at gmail.com> added the comment:

Hi Marie and many thanks for your great interview of Rick Hanson regarding inner strength. Will certainly be watching the interview again. You did a wonderful job I 

thought of guiding Rick from stepping stone to stepping stone through some of his writing. You two created a truly helpful program together. And I totally agree with you in your obviously heartfelt expression of gratitude to Rick for his work. I too always look forward to what he has to teach us. Thanks again. With very best wishes, Ruth Whetsel
<a href="https://www.sattamatka.company/">satta matka,indian matka, boss matka</a>

----------
components: +XML -Library (Lib)
nosy: +Joony898i
title: Redirect is not working correctly in urllib2 -> SEO Services Development & PHP development
type: behavior -> performance

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

From report at bugs.python.org  Fri Jan  3 15:41:49 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 03 Jan 2020 20:41:49 +0000
Subject: [issue14132] Redirect is not working correctly in urllib2
In-Reply-To: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za>
Message-ID: <1578084109.93.0.819298076645.issue14132@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy:  -Joony898i
title: SEO Services Development & PHP development -> Redirect is not working correctly in urllib2

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

From report at bugs.python.org  Fri Jan  3 16:24:18 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jan 2020 21:24:18 +0000
Subject: [issue6143] IDLE - clear and restart the shell window
In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>
Message-ID: <1578086658.46.0.332269819135.issue6143@roundup.psfhosted.org>


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

#17632 was instead closed as a duplicate of this issue.

The (editor) Run menu now has a custom run item.  'Clear shell before restart' could be added as an alternative to 'no restart'.  But this would be a separate issue.

----------
title: IDLE - an extension to clear the shell window -> IDLE - clear and restart the shell window

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

From report at bugs.python.org  Fri Jan  3 16:26:24 2020
From: report at bugs.python.org (Brian Quinlan)
Date: Fri, 03 Jan 2020 21:26:24 +0000
Subject: [issue39205] Hang when interpreter exits after
 ProcessPoolExecutor.shutdown(wait=False)
Message-ID: <1578086784.42.0.0982560626547.issue39205@roundup.psfhosted.org>


New submission from Brian Quinlan <brian at sweetapp.com>:

```
from concurrent.futures import ProcessPoolExecutor
import time

t = ProcessPoolExecutor(max_workers=3)
t.map(time.sleep, [1,2,3])
t.shutdown(wait=False)
```

Results in this exception and then a hang (i.e. Python doesn't terminate):
```
Exception in thread QueueManagerThread:
Traceback (most recent call last):
  File "/usr/local/google/home/bquinlan/cpython/Lib/threading.py", line 944, in _bootstrap_inner
    self.run()
  File "/usr/local/google/home/bquinlan/cpython/Lib/threading.py", line 882, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/google/home/bquinlan/cpython/Lib/concurrent/futures/process.py", line 352, in _queue_management_worker
    _add_call_item_to_queue(pending_work_items,
  File "/usr/local/google/home/bquinlan/cpython/Lib/concurrent/futures/process.py", line 280, in _add_call_item_to_queue
    call_queue.put(_CallItem(work_id,
  File "/usr/local/google/home/bquinlan/cpython/Lib/multiprocessing/queues.py", line 82, in put
    raise ValueError(f"Queue {self!r} is closed")
ValueError: Queue <concurrent.futures.process._SafeQueue object at 0x7f371c4ae7f0> is closed
```

----------
assignee: bquinlan
messages: 359257
nosy: bquinlan
priority: normal
severity: normal
status: open
title: Hang when interpreter exits after ProcessPoolExecutor.shutdown(wait=False)
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Fri Jan  3 16:29:24 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Jan 2020 21:29:24 +0000
Subject: [issue14132] Redirect is not working correctly in urllib2
In-Reply-To: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za>
Message-ID: <1578086964.5.0.82021322771.issue14132@roundup.psfhosted.org>


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


----------
components: +Library (Lib) -XML
type: performance -> behavior

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

From report at bugs.python.org  Fri Jan  3 16:29:39 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 03 Jan 2020 21:29:39 +0000
Subject: [issue14132] Redirect is not working correctly in urllib2
In-Reply-To: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za>
Message-ID: <1578086979.58.0.697022639794.issue14132@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jan  3 16:32:00 2020
From: report at bugs.python.org (David Bolen)
Date: Fri, 03 Jan 2020 21:32:00 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1578087120.72.0.790003434787.issue27973@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

Ok, I can confirm that the updated PR 17774 test passes under Windows (and still cleans up after itself).

----------

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

From report at bugs.python.org  Fri Jan  3 16:33:55 2020
From: report at bugs.python.org (Nicholas Feix)
Date: Fri, 03 Jan 2020 21:33:55 +0000
Subject: [issue39206] Modulefinder does not consider source file encoding
Message-ID: <1578087235.53.0.0551529290674.issue39206@roundup.psfhosted.org>


New submission from Nicholas Feix <snip3rnick at googlemail.com>:

The modulefinder._find_module(...) function returns file objects text mode for source modules using the system encoding.
ModuleFinder.load_module(...) can run into decoding issues when the source file encoding does not match the system default.

The prior implementation imp.find_module(...) detected the encoding correctly using the tokenize.detect_encoding(...) function.
With the following code segment the detection would work again with UTF-8 BOM and PEP 263 type cookies.

    encoding = None
    if 'b' not in mode:
        with open(file_path, 'rb') as file:
            encoding = tokenize.detect_encoding(file.readline)[0]

    file = open(file_path, mode, encoding=encoding)

----------
components: Library (Lib)
messages: 359259
nosy: Nicholas Feix
priority: normal
severity: normal
status: open
title: Modulefinder does not consider source file encoding
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Jan  3 16:44:04 2020
From: report at bugs.python.org (Yusef Shaban)
Date: Fri, 03 Jan 2020 21:44:04 +0000
Subject: [issue39207] concurrent.futures.ProcessPoolExecutor does not properly
 reap jobs and spawns too many workers
Message-ID: <1578087844.56.0.81762061225.issue39207@roundup.psfhosted.org>


New submission from Yusef Shaban <yus2047889 at gmail.com>:

This came up from a supporting library but the actual issue is within concurrent.futures.ProcessPool.

Discussion can be found at https://github.com/agronholm/apscheduler/issues/414

ProcessPoolExecutor does not properly spin down and spin up new processes. Instead, it simply re-claims existing processes to re-purpose them for new jobs. Is there no option or way to make it so that instead of re-claiming existing processes, it spins down the process and then spins up another one. This behavior is a lot better for garbage collection and will help to prevent memory leaks. 

ProcessPoolExecutor also spins up too many processes and ignores the max_workers argument. An example is my setting max_workers=10, but I am only utilizing 3 processes. One would expect given the documentation that I would have at most 4 processes, the main process, and the 3 worker processes. Instead, ProcessPoolExecutor spawns all 10 max_workers and lets the other 7 just sit there, even though they are not necessary.

----------
components: Library (Lib)
messages: 359260
nosy: yus2047889
priority: normal
severity: normal
status: open
title: concurrent.futures.ProcessPoolExecutor does not properly reap jobs and spawns too many workers
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Jan  3 17:16:03 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jan 2020 22:16:03 +0000
Subject: [issue39141] IDLE: system clear function returns 256 on Mac OS
 Catalina
In-Reply-To: <1577470559.68.0.805755696987.issue39141@roundup.psfhosted.org>
Message-ID: <1578089763.53.0.561676838878.issue39141@roundup.psfhosted.org>


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

Among other problems, the patch for #11820 uses a unix-only tcl function. 

In non-shell editor and output windows, Select all (Control-A at least on windows) Delete (or Backspace, or Cut to clipboard, ^X on Windows) clears the window.  Delete does not work for the read-only history portion of the Shell, hence the request for a separate menu item.

However, if an editor window is open, one can still get a clean Shell by closing Shell and re-opening with Run => Shell or running the file being edited.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE - clear and restart the shell window
title: IDLE Clear function returns 256 on Mac OS Catalina -> IDLE: system clear function returns 256 on Mac OS Catalina

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

From report at bugs.python.org  Fri Jan  3 17:48:56 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jan 2020 22:48:56 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578091736.26.0.585255011412.issue39152@roundup.psfhosted.org>


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

Your code is buggy because 'cursor' is not a dict or anything like one.

On the other hand, adding retval to capture and return the return from Widget.configure looks correct.  (And it will not prevent kw.update('cursor') from raising.  The current code is

    def configure(self, cnf=None, **kw):
        """Modify or query scale options.

        Setting a value for any of the "from", "from_" or "to" options
        generates a <<RangeChanged>> event."""
        if cnf:
            kw.update(cnf)
        Widget.configure(self, **kw)
        if any(['from' in kw, 'from_' in kw, 'to' in kw]):
            self.event_generate('<<RangeChanged>>')
)

To review, test, and make the change, a github Pull Request (PR) is needed.  I will make one.

----------
nosy: +serhiy.storchaka, terry.reedy

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

From report at bugs.python.org  Fri Jan  3 18:05:25 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jan 2020 23:05:25 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578092725.87.0.854100927196.issue39152@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jan  3 18:10:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 03 Jan 2020 23:10:00 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578093000.81.0.0765532282407.issue39152@roundup.psfhosted.org>


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

Giovanni, a Python exception is a intended exit.  A crash is when the program either hangs or stops unintentionally without a python exception but with an OS error message.

I checked and Scale is the only ttk widget that overrides configure.

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

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

From report at bugs.python.org  Fri Jan  3 18:49:27 2020
From: report at bugs.python.org (Kent Watsen)
Date: Fri, 03 Jan 2020 23:49:27 +0000
Subject: [issue31242] Add SSLContext.set_verify_callback()
In-Reply-To: <1503265756.53.0.967490588927.issue31242@psf.upfronthosting.co.za>
Message-ID: <1578095367.03.0.258191531474.issue31242@roundup.psfhosted.org>


Change by Kent Watsen <kent+python at watsen.net>:


----------
nosy: +kwatsen

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

From report at bugs.python.org  Fri Jan  3 19:04:37 2020
From: report at bugs.python.org (ThePokestarFan)
Date: Sat, 04 Jan 2020 00:04:37 +0000
Subject: [issue39208] PDB pm function throws exception without sys import
Message-ID: <1578096277.08.0.562262793407.issue39208@roundup.psfhosted.org>


New submission from ThePokestarFan <sarkaraoyan at gmail.com>:

When testing PDB in python 3.8.1, PDB throws an exception when I call the pm() function in PDB without importing system.

[Fresh session]
>>> import pdb
>>> pdb.pm()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/pdb.py", line 1631, in pm
    post_mortem(sys.last_traceback)
AttributeError: module 'sys' has no attribute 'last_traceback'
>>> import sys
>>> pdb.pm()
> /Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/pdb.py(1631)pm()
-> post_mortem(sys.last_traceback)
...

----------
components: Library (Lib), macOS
messages: 359264
nosy: ThePokestarFan, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: PDB pm function throws exception without sys import
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Jan  3 19:10:30 2020
From: report at bugs.python.org (ThePokestarFan)
Date: Sat, 04 Jan 2020 00:10:30 +0000
Subject: [issue6143] IDLE - clear and restart the shell window
In-Reply-To: <1243631391.82.0.146122427664.issue6143@psf.upfronthosting.co.za>
Message-ID: <1578096630.55.0.8210995759.issue6143@roundup.psfhosted.org>


ThePokestarFan <sarkaraoyan at gmail.com> added the comment:

I would really like to be able to clear IDLE when using it. I do not understand how hard it can be just to clear a window.

----------
nosy: +ThePokestarFan

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

From report at bugs.python.org  Fri Jan  3 19:11:39 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 04 Jan 2020 00:11:39 +0000
Subject: [issue39208] PDB pm function throws exception without sys import
In-Reply-To: <1578096277.08.0.562262793407.issue39208@roundup.psfhosted.org>
Message-ID: <1578096699.81.0.340751521616.issue39208@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Try varying the order of what you're doing there:

>>> import pdb, sys
>>> pdb.pm()
Traceback ...
>>> pdb.pm()
<post-mortem of the exception raised by the first call to pdb.pm()>

See https://docs.python.org/3/library/sys.html#sys.last_traceback, which notes that this attribute is not always present (it won't be if no exception has been raised).

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Jan  3 19:56:55 2020
From: report at bugs.python.org (Luciana)
Date: Sat, 04 Jan 2020 00:56:55 +0000
Subject: [issue39206] Modulefinder does not consider source file encoding
In-Reply-To: <1578087235.53.0.0551529290674.issue39206@roundup.psfhosted.org>
Message-ID: <1578099415.89.0.417926640854.issue39206@roundup.psfhosted.org>


Luciana <lucianadacostamarques at gmail.com> added the comment:

I just wanted to comment here that I am looking into this.

----------
nosy: +lucianamarques

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

From report at bugs.python.org  Fri Jan  3 20:17:53 2020
From: report at bugs.python.org (Kent Watsen)
Date: Sat, 04 Jan 2020 01:17:53 +0000
Subject: [issue31242] Add SSLContext.set_verify_callback()
In-Reply-To: <1503265756.53.0.967490588927.issue31242@psf.upfronthosting.co.za>
Message-ID: <1578100673.02.0.179839926135.issue31242@roundup.psfhosted.org>


Kent Watsen <kent+python at watsen.net> added the comment:

Very much needing this!

My situation is a mutli-tenant asynchio-based server whereby each tenant is able to configure other clients that can connect.  The current strategy requires all certs to be known up-front that, for now, necessitates a painful restart whenever new auth for a client-certificate is configured.

----------

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

From report at bugs.python.org  Fri Jan  3 20:40:19 2020
From: report at bugs.python.org (anthony shaw)
Date: Sat, 04 Jan 2020 01:40:19 +0000
Subject: [issue34946] inspect.getcallargs is marked as deprecated in
 documentation, but doesn't issue a DeprecationWarning when used
In-Reply-To: <1539108839.31.0.545547206417.issue34946@psf.upfronthosting.co.za>
Message-ID: <1578102019.14.0.52421321381.issue34946@roundup.psfhosted.org>


anthony shaw <anthonyshaw at apache.org> added the comment:

Resolved by another bpo

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

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

From report at bugs.python.org  Fri Jan  3 20:49:59 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 04 Jan 2020 01:49:59 +0000
Subject: [issue39206] Modulefinder does not consider source file encoding
In-Reply-To: <1578087235.53.0.0551529290674.issue39206@roundup.psfhosted.org>
Message-ID: <1578102599.47.0.51566967002.issue39206@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jan  3 21:06:15 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 04 Jan 2020 02:06:15 +0000
Subject: [issue39207] concurrent.futures.ProcessPoolExecutor does not properly
 reap jobs and spawns too many workers
In-Reply-To: <1578087844.56.0.81762061225.issue39207@roundup.psfhosted.org>
Message-ID: <1578103575.86.0.321590795311.issue39207@roundup.psfhosted.org>


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

> ProcessPoolExecutor does not properly spin down and spin up new processes.

It is because Process "Pool" is for reusing processes.
If you don't want to reuse process, you can use the Process.
https://docs.python.org/3/library/multiprocessing.html#the-process-class

Or you can create ProcessPoolExecutor before starting bunch of jobs and shutdown it after complete the jobs.


> ProcessPoolExecutor also spins up too many processes and ignores the max_workers argument.  An example is my setting max_workers=10,
[snip]
> Instead, ProcessPoolExecutor spawns all 10 max_workers

What "ignores the max_workers argument" means?

And would you create a simple reproducible example?

Old ThreadPoolExecutor had the behavior (#24882).  But ProcessPoolExecutor starts worker processes on demand from old.

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

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

From report at bugs.python.org  Fri Jan  3 21:13:52 2020
From: report at bugs.python.org (Anthony Wee)
Date: Sat, 04 Jan 2020 02:13:52 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578104032.83.0.0843002779957.issue29778@roundup.psfhosted.org>


Change by Anthony Wee <antxwee at gmail.com>:


----------
pull_requests: +17244
pull_request: https://github.com/python/cpython/pull/17818

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

From report at bugs.python.org  Fri Jan  3 21:14:22 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 04 Jan 2020 02:14:22 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1578104062.27.0.83711062689.issue27973@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset 5bba60290b4ac8c95ac46cfdaba5deee37be1fab by Senthil Kumaran in branch '2.7':
bpo-27973 - Use test.support.temp_dir instead of NamedTemporaryFile for the (#17774)
https://github.com/python/cpython/commit/5bba60290b4ac8c95ac46cfdaba5deee37be1fab


----------

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

From report at bugs.python.org  Fri Jan  3 21:20:51 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 04 Jan 2020 02:20:51 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1578104451.08.0.342229369832.issue27973@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


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

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

From report at bugs.python.org  Fri Jan  3 21:32:16 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 04 Jan 2020 02:32:16 +0000
Subject: [issue39196] json fails to encode dictionary view types
In-Reply-To: <1577992258.0.0.878269321128.issue39196@roundup.psfhosted.org>
Message-ID: <1578105136.31.0.107537321561.issue39196@roundup.psfhosted.org>


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

If we support more types by default, user can not customize serialization of the type using `default` option.
That's why we don't accept "any iterable" but only list and tuple.

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

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

From report at bugs.python.org  Fri Jan  3 21:32:27 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 04 Jan 2020 02:32:27 +0000
Subject: [issue39196] json fails to encode dictionary view types
In-Reply-To: <1577992258.0.0.878269321128.issue39196@roundup.psfhosted.org>
Message-ID: <1578105147.31.0.690637383139.issue39196@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


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

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

From report at bugs.python.org  Fri Jan  3 21:37:16 2020
From: report at bugs.python.org (James Brown)
Date: Sat, 04 Jan 2020 02:37:16 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1578105436.14.0.229216159334.issue27657@roundup.psfhosted.org>


James Brown <jbrown at easypost.com> added the comment:

This is a surprising change to put in a minor release. This change totally changes the semantics of parsing scheme-less URLs with ports in them and ended up breaking a significant amount of my software. It turns out that urls like `example.com:80` are more common than one might hope, and a lot of software has always assumed that `example.com:80` would get parsed as the netloc and the software can guess the scheme based on the port...

----------
nosy: +James Brown2

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

From report at bugs.python.org  Fri Jan  3 22:50:10 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 04 Jan 2020 03:50:10 +0000
Subject: [issue39204] Automate adding Type Annotations to Documentation
In-Reply-To: <1578078745.51.0.848404810387.issue39204@roundup.psfhosted.org>
Message-ID: <1578109810.85.0.743027718633.issue39204@roundup.psfhosted.org>


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

I am not sure if it was discussed earlier there was a discussion on adding PEP 570 syntax across the docs. This comes at the cost of keeping the types updated. There was also a poc over expanding the signature to view the PEP 570 syntax as needed. 

issue37134
https://bugs.python.org/msg344654

----------
nosy: +gvanrossum, pablogsal, rhettinger, xtreak

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

From report at bugs.python.org  Fri Jan  3 22:59:57 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 04 Jan 2020 03:59:57 +0000
Subject: [issue39204] Automate adding Type Annotations to Documentation
In-Reply-To: <1578078745.51.0.848404810387.issue39204@roundup.psfhosted.org>
Message-ID: <1578110397.82.0.824922745054.issue39204@roundup.psfhosted.org>


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

Some discussion on similar proposal earlier : https://mail.python.org/pipermail/python-dev/2017-November/150234.html

----------

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

From report at bugs.python.org  Fri Jan  3 23:21:19 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 04 Jan 2020 04:21:19 +0000
Subject: [issue39204] Automate adding Type Annotations to Documentation
In-Reply-To: <1578078745.51.0.848404810387.issue39204@roundup.psfhosted.org>
Message-ID: <1578111679.83.0.793924205393.issue39204@roundup.psfhosted.org>


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

This was never blocked on Python 2 (at best we'd do this for the most recent Python 3 release anyway).

I expect it will be quite complex to get the quality of the implementation high enough, but I suppose someone should start with a prototype. I'm not volunteering though. :-)

----------

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

From report at bugs.python.org  Sat Jan  4 00:18:06 2020
From: report at bugs.python.org (Andy Lester)
Date: Sat, 04 Jan 2020 05:18:06 +0000
Subject: [issue39146] too much memory consumption in re.compile unicode
In-Reply-To: <1577524829.3.0.724432739165.issue39146@roundup.psfhosted.org>
Message-ID: <1578115086.17.0.152446756917.issue39146@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
components: +Regular Expressions -Library (Lib)
nosy: +ezio.melotti, mrabarnett

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

From report at bugs.python.org  Sat Jan  4 00:24:16 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2020 05:24:16 +0000
Subject: [issue39154] "utf8" not always a synonym for "utf-8" in lib2to3
In-Reply-To: <1577641682.29.0.16123079146.issue39154@roundup.psfhosted.org>
Message-ID: <1578115456.36.0.928356428173.issue39154@roundup.psfhosted.org>


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


----------
nosy: +benjamin.peterson
stage:  -> test needed
versions: +Python 3.9 -Python 3.6

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

From report at bugs.python.org  Sat Jan  4 00:26:14 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 04 Jan 2020 05:26:14 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1578115574.56.0.137755930279.issue27657@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

@James - Originally the issue was considered a revert and the versions were set for the merge, but I certainly recognize the problem when parsing can fail for simple URLs like `localhost:8000` which is very common.

Another developer had raised the concerns with the change in this PR: https://github.com/python/cpython/pull/16839#issuecomment-570758153 

I am reopening this issue, and re-read the arguments again to understand and propose the next steps.

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

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

From report at bugs.python.org  Sat Jan  4 01:19:57 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2020 06:19:57 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1578118797.61.0.533435098719.issue39165@roundup.psfhosted.org>


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

I currently agree with Serhiy and am not persuaded that either new function is needed.

1. findalliter: For 3.0, I might have been more aggressive than we were in turning list-returning functions into iterators, as done with map, etc.  But the collective decision, led by Guido, was that for some, such as str.split, the efficiency gain was not worth the disruption.  The thought was that returned lists were typically 'small';  they are definitely finite (whereas map(func, infinite_iterator) is itself an infinite iterator).  It is too late to reverse that decision, and I would be wary of adding iterator versions.  There is no particular justification for this one.

2. findfirst: This seems to be a near duplicate of search.  

I don't know why people use findall(...)[0] instead of search (which I learned first), but I don't see 'lack of symmetry and completeness' as a reason. 'python-ideas' is a mailing list, not a person or even a defined group of people.  The respondents on any thread tend to be a biased selection of the community.  Such discussions suggest but do not determine.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Jan  4 01:31:21 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2020 06:31:21 +0000
Subject: [issue39169] TypeError: 'int' object is not callable if the signal
 handler is SIG_IGN
In-Reply-To: <1577750785.74.0.863762449142.issue39169@roundup.psfhosted.org>
Message-ID: <1578119481.88.0.0878276694533.issue39169@roundup.psfhosted.org>


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


----------
stage:  -> test needed
versions: +Python 3.9 -Python 3.6

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

From report at bugs.python.org  Sat Jan  4 01:34:56 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2020 06:34:56 +0000
Subject: [issue39174] unicodedata.normalize failing with NFD and NFKD for some
 characters in Python3
In-Reply-To: <1577816551.99.0.153382211706.issue39174@roundup.psfhosted.org>
Message-ID: <1578119696.39.0.703121194038.issue39174@roundup.psfhosted.org>


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


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

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

From report at bugs.python.org  Sat Jan  4 01:36:56 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2020 06:36:56 +0000
Subject: [issue39179] pandas tz_convert() seems to report incorrect date
 conversion
In-Reply-To: <1577888546.9.0.841265032585.issue39179@roundup.psfhosted.org>
Message-ID: <1578119816.36.0.0959388155986.issue39179@roundup.psfhosted.org>


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


----------
resolution:  -> third party
stage:  -> resolved

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

From report at bugs.python.org  Sat Jan  4 01:44:18 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2020 06:44:18 +0000
Subject: [issue39182] sys.addaudithook(hook) loops indefinitely on mismatch
 for hook
In-Reply-To: <1577899380.86.0.650724982572.issue39182@roundup.psfhosted.org>
Message-ID: <1578120258.52.0.713844882007.issue39182@roundup.psfhosted.org>


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

> I think this is specific to the interactive prompt.
In IDLE, which simulates interactive mode with repeated 'exec(user_code, namespace)', no error is printed, let alone a loop.

>>> import sys
>>> sys.addaudithook(0)
>>>

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Jan  4 01:51:48 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2020 06:51:48 +0000
Subject: [issue39182] sys.addaudithook(hook) loops indefinitely on mismatch
 for hook
In-Reply-To: <1577899380.86.0.650724982572.issue39182@roundup.psfhosted.org>
Message-ID: <1578120708.28.0.388062369024.issue39182@roundup.psfhosted.org>


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

I wrote too soon.  Entering anything at the next line prints
TypeError: 'int' object is not callable
twice and a lot of IDLE specific stuff, and not another prompt.  I have to restart the remote execution process.

----------

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

From report at bugs.python.org  Sat Jan  4 02:01:48 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2020 07:01:48 +0000
Subject: [issue39197] argparse: title and description for mutually exclusive
 arg groups
In-Reply-To: <1577995665.78.0.21290537011.issue39197@roundup.psfhosted.org>
Message-ID: <1578121308.45.0.987832631468.issue39197@roundup.psfhosted.org>


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


----------
nosy: +rhettinger
title: Support the title and description arguments for mutually exclusive argument groups -> argparse: title and description for mutually exclusive arg groups

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

From report at bugs.python.org  Sat Jan  4 04:16:02 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 04 Jan 2020 09:16:02 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578129362.8.0.125424355032.issue39191@roundup.psfhosted.org>


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


----------
pull_requests: +17246
pull_request: https://github.com/python/cpython/pull/17820

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

From report at bugs.python.org  Sat Jan  4 04:24:36 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 04 Jan 2020 09:24:36 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578129876.11.0.25425013856.issue39191@roundup.psfhosted.org>


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


----------
pull_requests: +17247
pull_request: https://github.com/python/cpython/pull/17821

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

From report at bugs.python.org  Sat Jan  4 04:49:22 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 04 Jan 2020 09:49:22 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578131362.65.0.378017251473.issue39191@roundup.psfhosted.org>


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


New changeset 867d8333ce6a7f74191ad464acc609d4a04e4acb by Andrew Svetlov in branch '3.8':
[3.8] bpo-39191: Don't spawn a task before failing (GH-17796) (GH-17820)
https://github.com/python/cpython/commit/867d8333ce6a7f74191ad464acc609d4a04e4acb


----------

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

From report at bugs.python.org  Sat Jan  4 04:49:36 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 04 Jan 2020 09:49:36 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578131376.33.0.715592333399.issue39191@roundup.psfhosted.org>


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


New changeset 9c145e19fba53369da5cd23a1e71de489836f827 by Andrew Svetlov in branch '3.7':
[3.7] bpo-39191: Don't spawn a task before failing (GH-17796) (#17821)
https://github.com/python/cpython/commit/9c145e19fba53369da5cd23a1e71de489836f827


----------

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

From report at bugs.python.org  Sat Jan  4 04:49:51 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 04 Jan 2020 09:49:51 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578131391.3.0.456912223777.issue39191@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Jan  4 07:46:26 2020
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Sat, 04 Jan 2020 12:46:26 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1578141986.26.0.513518260867.issue39165@roundup.psfhosted.org>


Juancarlo A?ez <apalala at gmail.com> added the comment:

There's no way to assert that `findall(...)[0]` is efficient enough in most cases. It is easy to see that that it is risky in every case, as runtime may be exponential, and memory O(len(input)). A mistake in the regular expression may easily result in an out-of-memory, which can only be debugged with a series of tests using `search()`.

A problem with `re.search(...)` is that id doesn't have the return value semantics of `findall(...)[0]`, and those semantics seem to be what appeal to Python programmers. It takes several lines of code (the ones in `findalliter()`) to have the same result as `findal(...)[0]` when using `search()`. `findall()` is the sole, lonely function in `re` with its return-value semantics.

Also this proposal embeds `first()` within the body of `findfirst(...)`, but by the implementation one should consider if `first()` shouldn't be part of `itertools`, perhaps with a different name, like `take_one()`.

One should also consider that although third-party extensions to `itertools` already provide the equivalent of `first()`, `findalliter()` and `findfirst()` do not belong there, and there are no mainstream third-party extensions to `re` where they would fit.

----------

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

From report at bugs.python.org  Sat Jan  4 07:56:47 2020
From: report at bugs.python.org (Thomas Wouters)
Date: Sat, 04 Jan 2020 12:56:47 +0000
Subject: [issue28367] Add more standard baud rate constants to "termios"
In-Reply-To: <1475695367.16.0.283640170005.issue28367@psf.upfronthosting.co.za>
Message-ID: <1578142607.28.0.336480501613.issue28367@roundup.psfhosted.org>


Thomas Wouters <thomas at python.org> added the comment:


New changeset 7dc72b8d4f2c9d1eed20f314fd6425eab66cbc89 by T. Wouters (Anthony Shaw) in branch 'master':
bpo-28367: Add additional baud rates for termios (GH-13142)
https://github.com/python/cpython/commit/7dc72b8d4f2c9d1eed20f314fd6425eab66cbc89


----------

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

From report at bugs.python.org  Sat Jan  4 07:57:13 2020
From: report at bugs.python.org (Thomas Wouters)
Date: Sat, 04 Jan 2020 12:57:13 +0000
Subject: [issue28367] Add more standard baud rate constants to "termios"
In-Reply-To: <1475695367.16.0.283640170005.issue28367@psf.upfronthosting.co.za>
Message-ID: <1578142633.45.0.696274884199.issue28367@roundup.psfhosted.org>


Change by Thomas Wouters <thomas at python.org>:


----------
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.7

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

From report at bugs.python.org  Sat Jan  4 08:14:30 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Jan 2020 13:14:30 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1578143670.94.0.954189337683.issue39165@roundup.psfhosted.org>


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

Your implementation takes several lines of code only because of complex semantic of findall() which you want to preserve in findfirst(). Actually findall() is an equivalent of one of three expressions, depending on the number of capturing groups in the regular expression:

    [m[0] for m in finditer(...)]
    [m[1] for m in finditer(...)]
    [m.groups() for m in finditer(...)]

so findfirst() is an equivalent of one of three expressions:

    search(...)[0]
    search(...)[1]
    search(...).groups()

In real code the number of capturing groups in the regular expression you use is known statically, so you should not dispatch one of above variants at run time. You just use the appropriate one.

findall() is older interface. More modern, generator and object interface is finditer(). findall() was not deprecated and was not converted to returning an iterator because many old code uses it, and we do not want to break it.

----------

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

From report at bugs.python.org  Sat Jan  4 08:40:58 2020
From: report at bugs.python.org (Giovanni Lombardo)
Date: Sat, 04 Jan 2020 13:40:58 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578145258.3.0.37397286896.issue39152@roundup.psfhosted.org>


Giovanni Lombardo <g.lombardo at protonmail.com> added the comment:

Hello Terry J. Reedy, first and foremost thanks for the time you've dedicated to this issue! I really appreciate you work!! Even if I work with Python since 2007, I'm new here, and not very well versed with this issue management system. This has been my first issue, hopefully not the last.. or maybe yes. Anyway, I'm going to clarify some points about your answers: 

1: scale.configure('whateveroption') can take the name of an option and should return its value, usually a tuple (unless you've already customized the option's value) as all other widgets already do. 

2. The code I've provided is not correct you're right. Mistakenly I've pasted the wrong one, but when I realized it, trying to delete and replace the uncorrect part, I've been unable to find the edit or delete feature on the issue tracker. Sorry for that.

3. I'd like to thank you for the clarification you've given about correct definition of crash and exception. I knew them. Anyway I'd like point out that there is no option in the 'create ticket' page of the issue tracker to specify that an exception that shouldn't be raised at all is instead raised. Considering that, if a piece of code is not supposed to raise exceptions managing them involve a runtime overhead we all want to avoid. Eventually the raising of the exception may stop an application abnormally leading to the same effect experienced in an application crash. 

4. Exaclty, Scale is the only one widget that override configure. So in theory no other similar issues should be found there.

It there is some action I need to do, or some documentation I need to read in order to be able to help here please point me there. Thank you again.

----------

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

From report at bugs.python.org  Sat Jan  4 08:41:21 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Jan 2020 13:41:21 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1578145281.42.0.200370355973.issue39158@roundup.psfhosted.org>


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

The documentation for ast.literal_eval():

   Safely evaluate an expression node or a string containing a Python literal or
   container display.  The string or node provided may only consist of the
   following Python literal structures: strings, bytes, numbers, tuples, lists,
   dicts, sets, booleans, and ``None``.

https://docs.python.org/3/library/ast.html#ast.literal_eval

If we are going to add support of a function call set(), we should change the documentation.

And if add support of non-literals, where should we stop? Should we support also frozenset() and bytearray()? inf and nan? infj and nanj? complex()? Ellipsis? __debug__?

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

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

From report at bugs.python.org  Sat Jan  4 08:45:20 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Jan 2020 13:45:20 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578145520.56.0.0792762233709.issue39152@roundup.psfhosted.org>


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

There is a special case in tests for Scale.configure. It should be removed now. And maybe there is an old issue for this?

----------

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

From report at bugs.python.org  Sat Jan  4 08:54:02 2020
From: report at bugs.python.org (Giovanni Lombardo)
Date: Sat, 04 Jan 2020 13:54:02 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578146042.37.0.753068811111.issue39152@roundup.psfhosted.org>


Giovanni Lombardo <g.lombardo at protonmail.com> added the comment:

@serhiy.storchaka I didn't found any old issue not closed aboud tkinter Scale widget.

----------

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

From report at bugs.python.org  Sat Jan  4 09:29:32 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 04 Jan 2020 14:29:32 +0000
Subject: [issue39209] Crash on REPL mode with long text copy and paste
Message-ID: <1578148172.19.0.147940927734.issue39209@roundup.psfhosted.org>


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

When I copy and paste the pretty long text into REPL shell.
REPL shell is crash down with segment fault.

This issue is only reproducible on macOS,
but Linux REPL doesn't look like normal behavior.

[origin text]
<?xml version="1.0" encoding="iso-8859-1"?>
<test>
    <Users>
        <fun25>
            <limits>
                <total>0KiB</total>
                <kbps>0</kbps>
                <rps>1.3</rps>
                <connections>0</connections>
            </limits>
            <usages>
                <total>16738211KiB</total>
                <kbps>237.15</kbps>
                <rps>1.3</rps>
                <connections>0</connections>
            </usages>
            <time_to_refresh>never</time_to_refresh>
            <limit_exceeded_URL>none</limit_exceeded_URL>
        </fun25>
    </Users>
</test>

[macOS]

Python 3.9.0a2+ (heads/master:7dc72b8d4f, Jan  4 2020, 23:22:45)
[Clang 11.0.0 (clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = """<?xml version="1.0" encoding="iso-8859-1"?>
... <test>
...     <Users>
...         <fun25>
...             <limits>
...                 <total>0KiB</total>
...                 <kbps>0</kbps>
...                 <rps>1.3</rps>
...                 <connections>0</connections>
...             </limits>
...             <usages>
...                 <total>16738211KiB</total>
...                 <kbps>237.15</kbps>
...                 <rps>1.3</rps>
...                 <connections>0</connections>
...             </usages>
...             <time_to_refresh>never</time_to_refresh>
...             <limit_exceeded_URL>none</limit_exceeded_URL>
...         </fun25>
...     </Users>
... </test>
... """
Assertion failed: ((intptr_t)(int)(a - line_start) == (a - line_start)), function parsetok, file Parser/parsetok.c, line 324.
[1]    13389 abort      ./python.exe


[linux]

Python 3.9.0a2+ (heads/master-dirty:7dc72b8, Jan  4 2020, 23:22:11)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = """<?xml version="1.0" encoding="iso-8859-1"?>
<test>
    <Users>
        <fun25>
            <limits>
                <total>0KiB</total>
                <kbps>0</kbps>
                <rps>true</rps>
                <connections>0</connections>
            </limits>
            <usages>
                <total>16738211KiB</total>
                <kbps>237.15</kbps>
                <rps>true</rps>
                <connections>0</connections>
            </usages>
            <time_to_refresh>never</time_to_refresh>
            <limit_exceeded_URL>none</limit_exceeded_URL>
        </fun25>
    </Users>
</test>
... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... """
>>> a
'<?xml version="1.0" encoding="iso-8859-1"?>\n<test>\n    <Users>\n        <fun25>\n            <limits>\n                <total>0KiB</total>\n                <kbps>0</kbps>\n                <rps>true</rps>\n                <connections>0</connections>\n            </limits>\n            <usages>\n                <total>16738211KiB</total>\n                <kbps>237.15</kbps>\n                <rps>true</rps>\n                <connections>0</connections>\n            </usages>\n            <time_to_refresh>never</time_to_refresh>\n            <limit_exceeded_URL>none</limit_exceeded_URL>\n        </fun25>\n    </Users>\n</test>\n'
>>>

----------
messages: 359290
nosy: corona10, pablogsal
priority: normal
severity: normal
status: open
title: Crash on REPL mode with long text copy and paste
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Sat Jan  4 09:31:31 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 04 Jan 2020 14:31:31 +0000
Subject: [issue39209] Crash on REPL mode with long text copy and paste
In-Reply-To: <1578148172.19.0.147940927734.issue39209@roundup.psfhosted.org>
Message-ID: <1578148291.2.0.917941255687.issue39209@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +serhiy.storchaka, vstinner

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

From report at bugs.python.org  Sat Jan  4 09:45:35 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 04 Jan 2020 14:45:35 +0000
Subject: [issue33095] Cross-reference isolated mode from relevant locations
In-Reply-To: <1521352636.34.0.467229070634.issue33095@psf.upfronthosting.co.za>
Message-ID: <1578149135.09.0.531261911618.issue33095@roundup.psfhosted.org>


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

Closing since PRs were merged. Thanks for the review.

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

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

From report at bugs.python.org  Sat Jan  4 10:02:35 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 04 Jan 2020 15:02:35 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1578150155.23.0.897056670073.issue39158@roundup.psfhosted.org>


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

> And if add support of non-literals, where should we stop? Should we support also frozenset() and bytearray()? inf and nan? infj and nanj? complex()? Ellipsis? __debug__?

Then the name of the function would be a bit misleading (for frozenset() and bytearray()), no? I think the set() change is somehow inconsistent already with the function name.

----------

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

From report at bugs.python.org  Sat Jan  4 10:29:55 2020
From: report at bugs.python.org (Yan Mitrofanov)
Date: Sat, 04 Jan 2020 15:29:55 +0000
Subject: [issue39210] Sorting falls back to use __gt__ when __lt__ is not
 present
Message-ID: <1578151795.43.0.682291916428.issue39210@roundup.psfhosted.org>


New submission from Yan Mitrofanov <mmxlviii at mail.ru>:

Sorting documentation claims that sorting algorithm is only using < comparisons
https://docs.python.org/3/howto/sorting.html#odd-and-ends
https://docs.python.org/3/library/stdtypes.html#list.sort

When __lt__ implementation is missing, you get an exception
class Foo:
    pass
sorted([Foo(), Foo(), Foo()])
TypeError: '<' not supported between instances of 'Foo' and 'Foo'

However, if implement __gt__ method, you doesn't get an exception
class Foo:
    def __gt__(self, other):
        return False
sorted([Foo(), Foo(), Foo()])  # ok


Is it supposed to work like this? Or is it lack of documentation?

----------
assignee: docs at python
components: Documentation
messages: 359293
nosy: docs at python, yanmitrofanov
priority: normal
severity: normal
status: open
title: Sorting falls back to use __gt__ when __lt__ is not present
versions: Python 3.8

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

From report at bugs.python.org  Sat Jan  4 11:06:54 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 04 Jan 2020 16:06:54 +0000
Subject: [issue39210] Sorting falls back to use __gt__ when __lt__ is not
 present
In-Reply-To: <1578151795.43.0.682291916428.issue39210@roundup.psfhosted.org>
Message-ID: <1578154014.77.0.0449355523007.issue39210@roundup.psfhosted.org>


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

The `<` comparison uses `__lt__` dunder if it exists, otherwise it falls back on `__gt__`.

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

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

From report at bugs.python.org  Sat Jan  4 11:19:52 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jan 2020 16:19:52 +0000
Subject: [issue39210] Sorting falls back to use __gt__ when __lt__ is not
 present
In-Reply-To: <1578151795.43.0.682291916428.issue39210@roundup.psfhosted.org>
Message-ID: <1578154792.68.0.680754568398.issue39210@roundup.psfhosted.org>


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

To be precise, when doing `a < b`, either `a.__lt__` or `b.__gt__` can be used, since `__gt__` is considered the reversed / reflected version of `__lt__` (analogous to `__add__` and `__radd__`).


>>> class A:
...     def __lt__(self, other): return False
... 
>>> class B:
...     def __gt__(self, other): return True
... 
>>> A() < B()
False
>>> B() < A()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '<' not supported between instances of 'B' and 'A'
>>> sorted([A(), B()])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '<' not supported between instances of 'B' and 'A'
>>> sorted([B(), A()])
[<__main__.B object at 0x10dc4cca0>, <__main__.A object at 0x10dc68ca0>]

Presumably in the normal case, all the objects being sorted have the same type, and so in that case it's enough that the type implements at least one of __lt__ and __gt__.

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

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

From report at bugs.python.org  Sat Jan  4 11:39:29 2020
From: report at bugs.python.org (AnLong)
Date: Sat, 04 Jan 2020 16:39:29 +0000
Subject: [issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily
In-Reply-To: <1542822100.42.0.788709270274.issue35292@psf.upfronthosting.co.za>
Message-ID: <1578155969.35.0.450420327276.issue35292@roundup.psfhosted.org>


Change by AnLong <aisk1988 at gmail.com>:


----------
pull_requests: +17248
pull_request: https://github.com/python/cpython/pull/17822

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

From report at bugs.python.org  Sat Jan  4 12:30:22 2020
From: report at bugs.python.org (Yan Mitrofanov)
Date: Sat, 04 Jan 2020 17:30:22 +0000
Subject: [issue39210] Sorting falls back to use __gt__ when __lt__ is not
 present
In-Reply-To: <1578151795.43.0.682291916428.issue39210@roundup.psfhosted.org>
Message-ID: <1578159022.53.0.504635120736.issue39210@roundup.psfhosted.org>


Yan Mitrofanov <mmxlviii at mail.ru> added the comment:

I got your point. So it seems that two pieces of documentation are not equivalent: 

https://docs.python.org/3/howto/sorting.html#odd-and-ends
> The sort routines are guaranteed to use __lt__() when making comparisons between two objects.

https://docs.python.org/3/library/stdtypes.html#list.sort
> This method sorts the list in place, using only < comparisons between items.

----------

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

From report at bugs.python.org  Sat Jan  4 12:49:08 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 04 Jan 2020 17:49:08 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1578160148.23.0.991301961336.issue27657@roundup.psfhosted.org>


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


----------
keywords: +3.7regression, 3.8regression -patch
priority: normal -> deferred blocker

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

From report at bugs.python.org  Sat Jan  4 12:55:31 2020
From: report at bugs.python.org (Tibor Baranya)
Date: Sat, 04 Jan 2020 17:55:31 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
 single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1578160531.01.0.70346062648.issue11416@roundup.psfhosted.org>


Tibor Baranya <tibi at fallen.hu> added the comment:

Just for further clarification on how .netrc is supposed to work, I tested some other implementations. Sorry if this comment gets too long, but it seems netrc is not really a standardized solution.

In my last comment I referred curl and wget, but of course the original implementation is ftp (which points to the netrc manual). The manual itself doesn't talk about priorities, but all the mentioned 3 tools are in common in that they take the first entry if the same machine is in the netrc file multiple times.

When trying to force using the second entry, though, breaks this consistency quickly: none of the above tools seem to support a query with host and login name provided.
ftp: doesn't support providing a user name from shell (and doesn't use netrc when opening a connection interactively)
curl: if username is provided, it interactively asks for a password and uses that (which may be an issue on my end, as source code suggested there is a login-based lookup)
wget: if username is provided without a password, it doesn't send a auth information at all (also wget doesn't send default auth information for http, which behavior can be altered somehow)

Actually these results suprised me, as I remembered I used host+login based lookup previously. And the answer was git clone via https: git's implementation is exactly what I would expect:
* if only host is provided, the first entry is used
* if both host and login is provided, it looks up the password for the appropriate login
* if no matching machine entry can be found, it uses the default entry
* it also supports login matching for the default entry

I'm about the send a pull request with my understanding on how netrc should work. Of course all comments are welcome, and I'm happy to alter the implementation (or break it up to smaller pieces if necessary). My priorities were:

* Not to break backward compatibility.
* Provide a way to consistently pick up the first entry, without the need to make modifications in all of the dependent libraries (see doc change).
* __repr__() had a bug: for the default entry, it gives 'machine default', instead of 'default'.
* another bug: 'machine default' is actually not supported, as the netrc.hosts dictionary cannot make a difference between the default entry and a machine called default (this has a partial fixed)

As r.david.murray mentioned, the hosts dictionary should probably be deprecated.

----------

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

From report at bugs.python.org  Sat Jan  4 13:09:07 2020
From: report at bugs.python.org (Tibor Baranya)
Date: Sat, 04 Jan 2020 18:09:07 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
 single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1578161347.72.0.962411164354.issue11416@roundup.psfhosted.org>


Change by Tibor Baranya <tibi at fallen.hu>:


----------
pull_requests: +17249
pull_request: https://github.com/python/cpython/pull/17823

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

From report at bugs.python.org  Sat Jan  4 13:09:23 2020
From: report at bugs.python.org (Josh Kamdjou)
Date: Sat, 04 Jan 2020 18:09:23 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1578161363.69.0.0756070083008.issue34480@roundup.psfhosted.org>


Change by Josh Kamdjou <jkamdjou at gmail.com>:


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

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

From report at bugs.python.org  Sat Jan  4 13:23:29 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 04 Jan 2020 18:23:29 +0000
Subject: [issue39210] Sorting falls back to use __gt__ when __lt__ is not
 present
In-Reply-To: <1578151795.43.0.682291916428.issue39210@roundup.psfhosted.org>
Message-ID: <1578162209.63.0.98464865124.issue39210@roundup.psfhosted.org>


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

Right, the HOWTO language could possibly be improved. The intended and practical message is that you *only* need to provide __lt__ everywhere for sort to work.

----------
nosy: +rhettinger, tim.peters

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

From report at bugs.python.org  Sat Jan  4 13:26:34 2020
From: report at bugs.python.org (Shane)
Date: Sat, 04 Jan 2020 18:26:34 +0000
Subject: [issue39211] Change in http.server default IP behavior?
Message-ID: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>


New submission from Shane <shanesmith4 at gmail.com>:

It seems to me that the direct invocation behavior for http.server changed, probably with Python 3.8 (I'm currently using 3.8.1 on Windows 10).  On 3.7.X I was able to use it as described in the docs (https://docs.python.org/3/library/http.server.html)

> python -m http.server 8000

and it would default to whatever IP address was available.  Now, in order for it to function at all (not return "This site can?t be reached" in Chrome), I have to bind it to a specific IP address (say, 127.0.0.1, sticking with the docs example).

> python -m http.server 8000 --bind 127.0.0.1

At which point it works fine.  So it's still quite usable for this purpose, though I was surprised and -simple as the solution is- the solution is less simple when you don't know it!

Was this an intended change?  Something something security, perhaps?  If so, should it be noted in the "What's new" of the docs?  And of course, there's always the slight possibility that some aspect of Windows or Chrome behavior changed, but based on the termal's response I don't think that's the case.

Thanks,

----------
messages: 359299
nosy: Shane Smith
priority: normal
severity: normal
status: open
title: Change in http.server default IP behavior?
versions: Python 3.8

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

From report at bugs.python.org  Sat Jan  4 13:26:57 2020
From: report at bugs.python.org (Shane)
Date: Sat, 04 Jan 2020 18:26:57 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578162417.66.0.613334965216.issue39211@roundup.psfhosted.org>


Change by Shane <shanesmith4 at gmail.com>:


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

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

From report at bugs.python.org  Sat Jan  4 13:27:10 2020
From: report at bugs.python.org (Derek Frombach)
Date: Sat, 04 Jan 2020 18:27:10 +0000
Subject: [issue38973] Shared Memory List Returns 0 Length
In-Reply-To: <1575484189.99.0.873814899855.issue38973@roundup.psfhosted.org>
Message-ID: <1578162430.1.0.739532949446.issue38973@roundup.psfhosted.org>


Change by Derek Frombach <neoredstone at gmail.com>:


Removed file: https://bugs.python.org/file48757/20191203_194951.jpg

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

From report at bugs.python.org  Sat Jan  4 13:28:48 2020
From: report at bugs.python.org (Josh Kamdjou)
Date: Sat, 04 Jan 2020 18:28:48 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1578162528.26.0.418351018915.issue34480@roundup.psfhosted.org>


Josh Kamdjou <jkamdjou at gmail.com> added the comment:

(Author of PR https://github.com/python/cpython/pull/17643)

Since the behavior of self.error() is determined by the subclass implementation, an Exception is not guaranteed. How should this be handled? It seems the options are:

- continue execution, in which case 'match' needs to be defined (I proposed initialization to None, which results in returning -1 on the next line)
- return a value
- raise an Exception

Happy to update the PR with @xtreak's test cases.

----------
nosy: +jkamdjou

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

From report at bugs.python.org  Sat Jan  4 13:30:55 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 04 Jan 2020 18:30:55 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578162655.82.0.230103588146.issue39211@roundup.psfhosted.org>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Sat Jan  4 13:52:25 2020
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 04 Jan 2020 18:52:25 +0000
Subject: [issue39212] Show qualified function name when giving arguments error
Message-ID: <1578163945.77.0.403027118696.issue39212@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

I recently got this familiar error:

    builtins.TypeError: __init__() takes 1 positional argument but 2 were given

It was annoying that I didn't know which `__init__` method was under discussion. I wish that Python used the `__qualname__` of the function to show this error message (and maybe others?) so it'll show like this: 

    builtins.TypeError: FooBar.__init__() takes 1 positional argument but 2 were given

If I'm not mistaken, the implementation of this error is in getargs.c in the function vgetargs1_impl.

----------
components: Interpreter Core
messages: 359302
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Show qualified function name when giving arguments error
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Sat Jan  4 14:01:29 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 04 Jan 2020 19:01:29 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578164489.08.0.0646803825617.issue39211@roundup.psfhosted.org>


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

Can you please paste the output of http.server as in the port and address printed as a log when started for different commands? As I can see from the history the binding process was changed to include IPv6 as default : https://github.com/python/cpython/pull/11767

----------

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

From report at bugs.python.org  Sat Jan  4 14:02:53 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 04 Jan 2020 19:02:53 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578164573.02.0.315335255902.issue39211@roundup.psfhosted.org>


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


----------
nosy: +jaraco

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

From report at bugs.python.org  Sat Jan  4 14:11:17 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2020 19:11:17 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1578165077.49.0.426229289188.issue39165@roundup.psfhosted.org>


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

After reading Serhiy's clarification of the old and wonky findall return api, I agree that reusing  it in an unneeded new function would be a retrograde move.  We should instead upgrade the documentation of the more flexible current functions.

For search, give these examples of common uses:
  search(...)[0]  # Get entire matched string.
  search(...)[1]  # Get first captured group string.
  search(...).groups()  # Get tuple of captured group strings.

Note that the first two (unlike findfirst) may be used even when there are 1/many groups.  If one has a pattern with multiple groups, one might want different return values for different applications of the pattern. Or one may add a group to a pattern to use as a backreference in the matching process, not to mark the substring one want to see.

For find: list and explain finditer ***first***.  Then list and explain findall as the old less-flexible list interface, kept for back compatibility, that is equivalent to one of the following, depending on whether the pattern has 0, 1, or multiple groups.

    [m[0] for m in finditer(...)]  # List of full-match strings.
    [m[1] for m in finditer(...)]  # List of captured strings.
    [m.groups() for m in finditer(...)]  # List of tuples of strings.

To me, the above is clearer than "If one or more groups are present in the pattern, return a list of groups; this will be a list of tuples if the pattern has more than one group."  The first clause implies tuples even with one group; the second denies that.  One must infer that for one group, the match is extracted from the tuple.

Again, using finditer is more flexible than using findall in that the return, which limited by the number of groups, is not determined by it.

Given that each function is documented twice, as method and combined module function, where should the expanded explanation go?  Currently, expanded explanations of search, match, and fullmatch are on the methods, which the same for split, sub, and escape are on the functions.  Instead, all should go on whichever set of listings is first.

I think https://docs.python.org/3/library/re.html#module-contents should be split in two sections: re.compile and compile flags; combined compile + method functions.  Then consider moving the functions below the method listings (and move explanations of all functions that are methods to the methods.  Or maybe interleave the methods and functions.

----------

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

From report at bugs.python.org  Sat Jan  4 14:17:36 2020
From: report at bugs.python.org (Joseph Sible)
Date: Sat, 04 Jan 2020 19:17:36 +0000
Subject: [issue39213] cmd should have a hook in the finally block of cmdloop
Message-ID: <1578165456.25.0.525966531081.issue39213@roundup.psfhosted.org>


New submission from Joseph Sible <josephcsible at gmail.com>:

Currently, the cmdloop function in cmd has a preloop hook, which runs before the large try block, and a postloop hook, which runs at the end of the body of the large try block. This isn't sufficient for subclasses to safely use readline.set_completion_display_matches_hook, since an exception in the large try block would mean that postloop doesn't get called, so there wouldn't be an opportunity to restore the old value of that callback. This is analogous to how we need the finally block ourself to restore the old value of the completer. Moving where postloop is called would be a breaking change, so we should probably create a new method instead, called postloop_finally or something.

----------
components: Library (Lib)
messages: 359305
nosy: Joseph Sible
priority: normal
severity: normal
status: open
title: cmd should have a hook in the finally block of cmdloop
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sat Jan  4 14:27:13 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2020 19:27:13 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578166033.79.0.168482420919.issue39152@roundup.psfhosted.org>


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

Giovanni, I saw that you gave a correct fix even if your example was wrong.  Currently, scale.configure returns None instead of the configuration.  Your patch fixes this.  Once I created a git branch to verify and test the fix, it was trivial to make a PR, so I did so.

My PR still needs to patch the ttk.scale test.  If you get an idea of what to do, before I do it, post on the PR if you have a github account, or here.

----------

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

From report at bugs.python.org  Sat Jan  4 14:40:23 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 04 Jan 2020 19:40:23 +0000
Subject: [issue39182] sys.addaudithook(hook) loops indefinitely on mismatch
 for hook
In-Reply-To: <1577899380.86.0.650724982572.issue39182@roundup.psfhosted.org>
Message-ID: <1578166823.19.0.00736649483174.issue39182@roundup.psfhosted.org>


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

Right, IDLE doesn't call exec/compile until _after_ the code is submitted, while the regular prompt calls it first and passes stdin as the source file (which then does a buffered read).

The loop occurs because the next action after an invalid input is to read another input, which is correct, it just doesn't (and cannot) detect the case where an error is raised _before_ the user presses Enter.

----------

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

From report at bugs.python.org  Sat Jan  4 14:47:56 2020
From: report at bugs.python.org (Frew Schmidt)
Date: Sat, 04 Jan 2020 19:47:56 +0000
Subject: [issue11416] netrc module does not handle multiple entries for a
 single host
In-Reply-To: <1299446047.69.0.767438398088.issue11416@psf.upfronthosting.co.za>
Message-ID: <1578167276.16.0.267580388199.issue11416@roundup.psfhosted.org>


Change by Frew Schmidt <frioux at gmail.com>:


----------
nosy:  -Frew Schmidt

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

From report at bugs.python.org  Sat Jan  4 15:21:32 2020
From: report at bugs.python.org (Shane)
Date: Sat, 04 Jan 2020 20:21:32 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578169292.78.0.541593730383.issue39211@roundup.psfhosted.org>


Shane <shanesmith4 at gmail.com> added the comment:

For the basic invocation:

>python -m http.server 8080
Serving HTTP on :: port 8080 (http://[::]:8080/) ...

It just sits there, because I can't access it (http://[::]:8080/ is not a valid address, so far as I know, and inserting my IP address doesn't find it either).  If I bind it to an IP address, it works as expected (using 127.0.0.1 from the docs, for the sake of consistency).  For the following messages, I'm starting up the server in my user directory, browsing to http://127.0.0.1:8080/ in Chrome, and following the Documents link.

>python -m http.server 8080 --bind 127.0.0.1
Serving HTTP on 127.0.0.1 port 8080 (http://127.0.0.1:8080/) ...
127.0.0.1 - - [04/Jan/2020 15:15:18] "GET / HTTP/1.1" 200 -
127.0.0.1 - - [04/Jan/2020 15:15:18] code 404, message File not found
127.0.0.1 - - [04/Jan/2020 15:15:18] "GET /favicon.ico HTTP/1.1" 404 -
127.0.0.1 - - [04/Jan/2020 15:15:28] "GET /Documents/ HTTP/1.1" 200 -

----------

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

From report at bugs.python.org  Sat Jan  4 17:33:35 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 04 Jan 2020 22:33:35 +0000
Subject: [issue39214] Add curses.window.in_wch
Message-ID: <1578177215.08.0.364585714734.issue39214@roundup.psfhosted.org>


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

(I've already got a patch for this, just making the necessary issue)

curses.window.inch is pretty useless for any non-ascii character

----------
components: Extension Modules
messages: 359309
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: Add curses.window.in_wch
versions: Python 3.9

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

From report at bugs.python.org  Sat Jan  4 17:41:13 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 04 Jan 2020 22:41:13 +0000
Subject: [issue39212] Show qualified function name when giving arguments error
In-Reply-To: <1578163945.77.0.403027118696.issue39212@roundup.psfhosted.org>
Message-ID: <1578177673.63.0.599875618297.issue39212@roundup.psfhosted.org>


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

> builtins.TypeError: __init__() takes 1 positional argument but 2 were given

How did you get the fully qualified exception? I just get "TypeError". (Also the error message is different in 3.8.)


> It was annoying that I didn't know which `__init__` method was under discussion.

Couldn't you tell from the stacktrace showing the failed line of code?

I don't know about this. While I can certainly see that there are circumstances where it might be useful (e.g. you're running a .pyc file and there's no source line available), I think that in the majority of the cases showing fully-qualified names would be more annoying than useful, and certainly more intimidating to beginners.

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

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

From report at bugs.python.org  Sat Jan  4 18:44:05 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Sat, 04 Jan 2020 23:44:05 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1578181445.92.0.57194572588.issue39184@roundup.psfhosted.org>


Change by Saiyang Gou <gousaiyang223 at gmail.com>:


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

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

From report at bugs.python.org  Sat Jan  4 18:56:26 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sat, 04 Jan 2020 23:56:26 +0000
Subject: [issue39214] Add curses.window.in_wch
In-Reply-To: <1578177215.08.0.364585714734.issue39214@roundup.psfhosted.org>
Message-ID: <1578182186.27.0.720465701048.issue39214@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


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

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

From report at bugs.python.org  Sat Jan  4 19:11:33 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Sun, 05 Jan 2020 00:11:33 +0000
Subject: [issue39184] Many command execution functions are not raising
 auditing events
In-Reply-To: <1577920203.73.0.648457466575.issue39184@roundup.psfhosted.org>
Message-ID: <1578183093.79.0.610853888441.issue39184@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

I have made PR 17824 to add auditing events for the command execution functions mentioned above.

After a review on other related Python modules, I think maybe the following functions can also be audited, but a discussion may be required to determine whether they are necessary (whether these actions are sensitive enough to record, and performance trade off). 

- os.getenv/putenv/unsetenv
- os.getcwd/chdir
- os.chown/chmod
- os.stat/access
- os.link/symlink
- os.rename/renames/replace
- os.mkdir/mkdirs
- os.remove/removedirs/rmdir/unlink  (`shutil.rmtree` is already audited)
- os.add_dll_directory
- os.fork
- os.kill/killpg
- os.path.exists/isfile/isdir/...
- signal.pthread_kill
- shutil.copy*  (`shutil.copytree` is already audited)
- shutil.move
- shutil.chown
- shutil.unpack_archive  (`shutil.make_archive` is already audited)
- resource.prlimit
- file operations in `msvcrt`
- functions in `fcntl`, `syslog`
- many high level networking modules such as `http.client/server`, `socketserver`, `xmlrpc`  (the low-level `socket` calls are already audited)

----------

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

From report at bugs.python.org  Sat Jan  4 19:30:24 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 05 Jan 2020 00:30:24 +0000
Subject: [issue39215] Type Annotation of nested function with positional only
 arguments triggers SystemError
Message-ID: <1578184224.6.0.82739775738.issue39215@roundup.psfhosted.org>


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

def f():
    def g(arg: int, /):
        pass

f()


$ python3.9 t2.py
Traceback (most recent call last):
  File "/home/asottile/workspace/t2.py", line 5, in <module>
    f()
  File "/home/asottile/workspace/t2.py", line 2, in f
    def g(arg: int, /):
SystemError: no locals when loading 'int'

Originally from this StackOverflow post: https://stackoverflow.com/q/59594494/812183

----------
components: Interpreter Core
messages: 359312
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: Type Annotation of nested function with positional only arguments triggers SystemError
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Jan  4 19:35:43 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 05 Jan 2020 00:35:43 +0000
Subject: [issue39215] Type Annotation of nested function with positional only
 arguments triggers SystemError
In-Reply-To: <1578184224.6.0.82739775738.issue39215@roundup.psfhosted.org>
Message-ID: <1578184543.53.0.800206955145.issue39215@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

Looks as though annotations are using `LOAD_NAME` when they should probably use `LOAD_GLOBAL`?

```
$ diff -u <(python3.9 -m dis t2.py | sed 's/0x[a-f0-9]*/0xdeadbeef/g;s/t2\.py/FILENAME/g') <(python3.9 -m dis t3.py | sed 's/0x[a-f0-9]*/0xdeadbeef/g;s/t3\.py/FILENAME/g')
--- /dev/fd/63	2020-01-04 16:34:27.372004436 -0800
+++ /dev/fd/62	2020-01-04 16:34:27.372004436 -0800
@@ -10,7 +10,7 @@
              16 RETURN_VALUE
 
 Disassembly of <code object f at 0xdeadbeef, file "FILENAME", line 1>:
-  2           0 LOAD_NAME                0 (int)
+  2           0 LOAD_GLOBAL              0 (int)
               2 LOAD_CONST               1 (('arg',))
               4 BUILD_CONST_KEY_MAP      1
               6 LOAD_CONST               2 (<code object g at 0xdeadbeef, file "FILENAME", line 2>)
```

t3.py is the same as t2.py but without positional-only arguments

----------

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

From report at bugs.python.org  Sat Jan  4 20:12:07 2020
From: report at bugs.python.org (Kevin Schlossser)
Date: Sun, 05 Jan 2020 01:12:07 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1578186727.72.0.757294489245.issue38597@roundup.psfhosted.org>


Kevin Schlossser <kevin.g.schlosser at gmail.com> added the comment:

Thank you msg356892 for spear heading this for me. I family things to attend to so I apologize for opening this bug report and then walking away..

As far as recreating this issue. It simple to do. you can either use cython or you can put together a quick script that will make say 150 extensions. put one  line of code in it and compile it.. The results always end up being the same 123 extensions can be loaded on the 124th a TB happens.. It does not matter where the files are inside the package. it is always the 124th one that gets loaded for any one package. importing a pyd from another package does not change the number. The extensions have to be a direct descendant of one single package.

----------

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

From report at bugs.python.org  Sat Jan  4 20:14:43 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 05 Jan 2020 01:14:43 +0000
Subject: [issue39215] Type Annotation of nested function with positional only
 arguments triggers SystemError
In-Reply-To: <1578184224.6.0.82739775738.issue39215@roundup.psfhosted.org>
Message-ID: <1578186883.98.0.791148821148.issue39215@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

this triggers an assertion when run with debug enabled:

$ gdb ./python 
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./python...done.
warning: File "/home/asottile/workspace/cpython/python-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /home/asottile/workspace/cpython/python-gdb.py
line to your configuration file "/home/asottile/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/asottile/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
(gdb) run t2.py
Starting program: /home/asottile/workspace/cpython/python t2.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
python: Python/compile.c:3545: compiler_nameop: Assertion `scope || PyUnicode_READ_CHAR(name, 0) == '_'' failed.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff7060801 in __GI_abort () at abort.c:79
#2  0x00007ffff705039a in __assert_fail_base (
    fmt=0x7ffff71d77d8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=assertion at entry=0x555555815190 "scope || PyUnicode_READ_CHAR(name, 0) == '_'", file=file at entry=0x555555814233 "Python/compile.c", 
    line=line at entry=3545, 
    function=function at entry=0x555555814180 <__PRETTY_FUNCTION__.17589> "compiler_nameop") at assert.c:92
#3  0x00007ffff7050412 in __GI___assert_fail (
    assertion=assertion at entry=0x555555815190 "scope || PyUnicode_READ_CHAR(name, 0) == '_'", file=file at entry=0x555555814233 "Python/compile.c", 
    line=line at entry=3545, 
    function=function at entry=0x555555814180 <__PRETTY_FUNCTION__.17589> "compiler_nameop") at assert.c:101
#4  0x000055555568e946 in compiler_nameop (c=0x7fffffffdb40, 
    name=<optimized out>, ctx=Load) at Python/compile.c:3545
#5  0x000055555569020e in compiler_visit_expr1 (c=c at entry=0x7fffffffdb40, 
    e=0x555555b739d0) at Python/compile.c:5027
#6  0x000055555569027f in compiler_visit_expr (c=0x7fffffffdb40, 
    e=<optimized out>) at Python/compile.c:5052
#7  0x0000555555693570 in compiler_visit_argannotation (
    c=c at entry=0x7fffffffdb40, id=0x7ffff7f95d60, annotation=<optimized out>, 
    names=names at entry=0x7ffff66217d0) at Python/compile.c:2045
#8  0x000055555569363e in compiler_visit_argannotations (
    c=c at entry=0x7fffffffdb40, args=0x555555b739c0, 
    names=names at entry=0x7ffff66217d0) at Python/compile.c:2066
#9  0x00005555556936b2 in compiler_visit_annotations (
    c=c at entry=0x7fffffffdb40, args=args at entry=0x555555b73a28, 
    returns=returns at entry=0x0) at Python/compile.c:2094
#10 0x00005555556939fc in compiler_function (c=0x7fffffffdb40, 
    s=0x555555b73ab8, is_async=is_async at entry=0) at Python/compile.c:2214
#11 0x0000555555693dad in compiler_visit_stmt (c=c at entry=0x7fffffffdb40, 
    s=0x555555b73ab8) at Python/compile.c:3332
---Type <return> to continue, or q <return> to quit---
#12 0x0000555555693b8f in compiler_function (c=0x7fffffffdb40, 
    s=<optimized out>, is_async=is_async at entry=0) at Python/compile.c:2238
#13 0x0000555555693dad in compiler_visit_stmt (c=c at entry=0x7fffffffdb40, 
    s=0x555555b73b00) at Python/compile.c:3332
#14 0x0000555555694022 in compiler_body (c=c at entry=0x7fffffffdb40, 
    stmts=0x555555b73960) at Python/compile.c:1816
#15 0x0000555555694754 in compiler_mod (c=c at entry=0x7fffffffdb40, 
    mod=mod at entry=0x555555b73c00) at Python/compile.c:1836
#16 0x000055555569682b in PyAST_CompileObject (mod=mod at entry=0x555555b73c00, 
    filename=filename at entry=0x7ffff662a7b0, flags=flags at entry=0x7fffffffddc0, 
    optimize=optimize at entry=-1, arena=arena at entry=0x7ffff7e69640)
    at Python/compile.c:364
#17 0x00005555556c20cc in run_mod (mod=mod at entry=0x555555b73c00, 
    filename=filename at entry=0x7ffff662a7b0, 
    globals=globals at entry=0x7ffff7ecf3b0, locals=locals at entry=0x7ffff7ecf3b0, 
    flags=flags at entry=0x7fffffffddc0, arena=arena at entry=0x7ffff7e69640)
    at Python/pythonrun.c:1138
#18 0x00005555556c530c in PyRun_FileExFlags (fp=fp at entry=0x555555b6d000, 
    filename_str=filename_str at entry=0x7ffff7ecf720 "/home/asottile/workspace/cpython/t2.py", start=start at entry=257, globals=globals at entry=0x7ffff7ecf3b0, 
    locals=locals at entry=0x7ffff7ecf3b0, closeit=closeit at entry=1, 
    flags=0x7fffffffddc0) at Python/pythonrun.c:1063
#19 0x00005555556c56e6 in PyRun_SimpleFileExFlags (fp=fp at entry=0x555555b6d000, 
    filename=<optimized out>, 
    filename at entry=0x7ffff7ecf720 "/home/asottile/workspace/cpython/t2.py", 
    closeit=closeit at entry=1, flags=flags at entry=0x7fffffffddc0)
    at Python/pythonrun.c:428
#20 0x00005555556c58e9 in PyRun_AnyFileExFlags (fp=fp at entry=0x555555b6d000, 
    filename=0x7ffff7ecf720 "/home/asottile/workspace/cpython/t2.py", 
    closeit=closeit at entry=1, flags=flags at entry=0x7fffffffddc0)
    at Python/pythonrun.c:86
#21 0x00005555555aceca in pymain_run_file (config=config at entry=0x555555b2f190, 
    cf=cf at entry=0x7fffffffddc0) at Modules/main.c:369
#22 0x00005555555ad698 in pymain_run_python (
    exitcode=exitcode at entry=0x7fffffffddf4) at Modules/main.c:553
#23 0x00005555555ad703 in Py_RunMain () at Modules/main.c:632
#24 0x00005555555ad77d in pymain_main (args=args at entry=0x7fffffffde50)
    at Modules/main.c:662
#25 0x00005555555ad843 in Py_BytesMain (argc=<optimized out>, 
    argv=<optimized out>) at Modules/main.c:686
---Type <return> to continue, or q <return> to quit---
#26 0x00005555555ac053 in main (argc=<optimized out>, argv=<optimized out>)
    at ./Programs/python.c:16

----------

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

From report at bugs.python.org  Sat Jan  4 20:28:16 2020
From: report at bugs.python.org (Feng Yu)
Date: Sun, 05 Jan 2020 01:28:16 +0000
Subject: [issue22543] -W option cannot use non-standard categories
In-Reply-To: <1412285520.72.0.615712160291.issue22543@psf.upfronthosting.co.za>
Message-ID: <1578187696.46.0.361169345651.issue22543@roundup.psfhosted.org>


Feng Yu <rainwoodman at gmail.com> added the comment:

Coming here from https://github.com/astropy/astropy/issues/9832#issuecomment-570751353

Importing the named module during warning initialization is somewhat like code injection. And it may introduce unintended side-effects -- for example if this causes some 3rd party libraries to initialize too early?

String matching on the class name of every class in the hierarchy is safer, as there is no 'expected' code execution.

----------
nosy: +Feng Yu

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

From report at bugs.python.org  Sat Jan  4 20:30:30 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 05 Jan 2020 01:30:30 +0000
Subject: [issue39215] Type Annotation of nested function with positional only
 arguments triggers SystemError
In-Reply-To: <1578184224.6.0.82739775738.issue39215@roundup.psfhosted.org>
Message-ID: <1578187830.75.0.374324431084.issue39215@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


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

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

From report at bugs.python.org  Sat Jan  4 20:32:21 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 05 Jan 2020 01:32:21 +0000
Subject: [issue39216] ast_opt.c -- missing posonlyargs?
Message-ID: <1578187941.0.0.50477954259.issue39216@roundup.psfhosted.org>


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

while fixing bpo-39215, I noticed that there seems to be a place here where posonlyargs was missed: https://github.com/python/cpython/blob/7dc72b8d4f2c9d1eed20f314fd6425eab66cbc89/Python/ast_opt.c#L617-L627

not sure if this is intentional or not -- happy to make a patch which adds a line there if someone can help me with the test

----------
components: Interpreter Core
messages: 359317
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: ast_opt.c -- missing posonlyargs?
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Jan  4 20:58:49 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 01:58:49 +0000
Subject: [issue39215] Type Annotation of nested function with positional only
 arguments triggers SystemError
In-Reply-To: <1578184224.6.0.82739775738.issue39215@roundup.psfhosted.org>
Message-ID: <1578189529.69.0.930839164935.issue39215@roundup.psfhosted.org>


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


----------
pull_requests: +17255
pull_request: https://github.com/python/cpython/pull/17827

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

From report at bugs.python.org  Sat Jan  4 20:59:59 2020
From: report at bugs.python.org (Kevin Schlossser)
Date: Sun, 05 Jan 2020 01:59:59 +0000
Subject: [issue39217] GC of a ctypes object causes application crash
Message-ID: <1578189599.82.0.182987253345.issue39217@roundup.psfhosted.org>


New submission from Kevin Schlossser <kevin.g.schlosser at gmail.com>:

I guess this is a question as much as it is a bug report. I know that all kinds of strange behavior can happen when using ctypes improperly. This is what is taking place. I can provide code if needed. but lets work off of my description of what is taking place first.

I am querying DeviceIoControl which is apart of the Windows API..

I have a function that has ctypes objects passed to it.. it does whatever it is that is needed to call DeviceIoControl. I have narrow it down to a single object and I ran the visual studio debugger and it traced the problem back to the garbage collector.

So this is the basic layout..


```python

def IOControl(io_ctrl, inBuffer, outBuffer, outBufferSize=None):


    if outBuffer is None:
        outBufferSize = INT(0) 

    else:
        pOutBuffer = ctypes.byref(outBuffer)

        if outBufferSize is None:
            outBufferSize = INT(ctypes.sizeof(outBuffer))
        else:
            outBufferSize = INT(outBufferSize)


    if inBuffer is None:
        inBufferSize = INT(0) 
    else:
        pInBuffer = ctypes.byref(inBuffer)
        inBufferSize = INT(ctypes.sizeof(inBuffer))

    DeviceIOControl(
         io_ctrl, 
         inBuffer, 
         ctypes.byref(inBufferSize), 
         outBuffer,
         ctypes.byref(outBufferSize)
    )

    class SomeStructure(ctypes.Structure):

        _fields_ = [
            ('SomeField1', ULONG),
            ('SomeField2, LONG * 100,
        ]




out_buffer = SomeStructure()
buf_size = ctypes.sizeof(out_buffer)

IOControl(
    'some io control code', 
    None, 
    None, 
    out_buffer , 
    buf_size
]
 
```


The code above will crash Python and the debug leads back to an error in the GC.


I do not know what the internals of ctypes are or how they function. when using ctypes.byref() to create a pointer I would imagine that the original instance is held somewhere inside of the pointer. But when it gets passed off to the Windows function where it does or what it does is unknown to me. The process if doing this is more complex then what is above It is for example purposes.. There is another in the Windows API that will wait for data to be had from the first function call.

The funny thing is the first time it goes though IOControl without incident. its repeated attempts that cause the appcrash. 

If someone has a reason as to why this is taking place I am ready to learn!!!... I find it odd behavior that once i mode the code from that function into the same namespace where that function was originally called form everything works fine and no application crashes happen 


The debugger pointed to data that was being passed to a GC macro or function that did not have the information correct. It was pretty car into the GC code before the application crash happens. 

I am also able to provide the results of running the debugger

any help/information would be greatly appreciated.

----------
components: ctypes
messages: 359318
nosy: Kevin Schlossser
priority: normal
severity: normal
status: open
title: GC of a ctypes object causes application crash
type: crash
versions: Python 2.7, Python 3.7

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

From report at bugs.python.org  Sat Jan  4 21:15:30 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 02:15:30 +0000
Subject: [issue39215] Type Annotation of nested function with positional only
 arguments triggers SystemError
In-Reply-To: <1578184224.6.0.82739775738.issue39215@roundup.psfhosted.org>
Message-ID: <1578190530.39.0.973085178768.issue39215@roundup.psfhosted.org>


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

Thanks, Anthony, for the quick fix and the investigation! :)

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

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

From report at bugs.python.org  Sat Jan  4 21:19:49 2020
From: report at bugs.python.org (Tim Peters)
Date: Sun, 05 Jan 2020 02:19:49 +0000
Subject: [issue39210] Sorting falls back to use __gt__ when __lt__ is not
 present
In-Reply-To: <1578151795.43.0.682291916428.issue39210@roundup.psfhosted.org>
Message-ID: <1578190789.18.0.427802227496.issue39210@roundup.psfhosted.org>


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

It's hard to be clearer without being annoyingly wordy.  The truth is that sort does all comparisons by calling the CAPI:

    PyObject_RichCompareBool(v, w, Py_LT)`

Sorting doesn't know (or care) how `PyObject_RichCompareBool()` is implemented.  The closest Python equivalent is:

    bool(v < w)

although then you also have to be clear that `bool` refers to the builtin function of that name.

Regardless, the sorting docs certainly aren't the place to explain how `v < w` is implemented.  For example, that it _may_ end up calling `w.__gt__(v)` has nothing to do with sorting - instead that's about the semantics of comparison operators, regardless of context.

Since, best I can recall, nobody has asked about this before, perhaps the docs don't need "improvement" ;-)  If they do, then I'm with Mark:  the _intent_ was to say "if you want a class to implement its own sorting order, then it's sufficient to implement `__lt__` alone, and then sorting will use only that comparison operator if the list contains only instances of that class".

----------

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

From report at bugs.python.org  Sat Jan  4 21:35:48 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 05 Jan 2020 02:35:48 +0000
Subject: [issue39216] ast_opt.c -- missing posonlyargs?
In-Reply-To: <1578187941.0.0.50477954259.issue39216@roundup.psfhosted.org>
Message-ID: <1578191748.26.0.397612056289.issue39216@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Jan  4 22:05:15 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 05 Jan 2020 03:05:15 +0000
Subject: [issue39198] Lock may not be released in Logger.isEnabledFor
In-Reply-To: <1577995820.85.0.483829284775.issue39198@roundup.psfhosted.org>
Message-ID: <1578193515.22.0.557733583177.issue39198@roundup.psfhosted.org>


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


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Sat Jan  4 22:36:10 2020
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 05 Jan 2020 03:36:10 +0000
Subject: [issue39174] unicodedata.normalize failing with NFD and NFKD for some
 characters in Python3
In-Reply-To: <1577816551.99.0.153382211706.issue39174@roundup.psfhosted.org>
Message-ID: <1578195370.28.0.223687779478.issue39174@roundup.psfhosted.org>


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

I can not get what you say.  If "unicodedata.normalize() produces the correct sequence", isn't it just a your terminal behavior?

If you think it is Python's issue, could you be more specific and write a simple sample code?

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

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

From report at bugs.python.org  Sat Jan  4 23:37:37 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 05 Jan 2020 04:37:37 +0000
Subject: [issue39210] Sorting falls back to use __gt__ when __lt__ is not
 present
In-Reply-To: <1578190789.18.0.427802227496.issue39210@roundup.psfhosted.org>
Message-ID: <20200105043715.GO21130@ando.pearwood.info>


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

On Sun, Jan 05, 2020 at 02:19:49AM +0000, Tim Peters wrote:

> Since, best I can recall, nobody has asked about this before

See discussion here:

https://mail.python.org/archives/list/python-dev at python.org/message/5AQMG6ADD6RGPLI3VTILB2MKXMBFTIGU/

which followed from discussions on sort order. I was asked to provide a 
PR, but I have technical difficulties with github.

I think it's sufficient to say that sorting relies only on the `<` 
operator, and link to the section of the docs that map special dunders 
to comparison operators, namely here:

https://docs.python.org/3/reference/datamodel.html#object.__lt__

where it goes into detail about reflected methods and such.

----------

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

From report at bugs.python.org  Sun Jan  5 00:34:52 2020
From: report at bugs.python.org (Reed)
Date: Sun, 05 Jan 2020 05:34:52 +0000
Subject: [issue39218] Assertion failure when calling statistics.variance() on
 a float32 Numpy array
Message-ID: <1578202492.29.0.981939629191.issue39218@roundup.psfhosted.org>


New submission from Reed <readuw at gmail.com>:

If a float32 Numpy array is passed to statistics.variance(), an assertion failure occurs. For example:

    import statistics
    import numpy as np
    x = np.array([1, 2], dtype=np.float32)
    statistics.variance(x)

The assertion error is:

    assert T == U and count == count2

Even if you convert x to a list with `x = list(x)`, the issue still occurs. The issue is caused by the following lines in statistics.py (https://github.com/python/cpython/blob/ec007cb43faf5f33d06efbc28152c7fdcb2edb9c/Lib/statistics.py#L687-L691):

    T, total, count = _sum((x-c)**2 for x in data)
    # The following sum should mathematically equal zero, but due to rounding
    # error may not.
    U, total2, count2 = _sum((x-c) for x in data)
    assert T == U and count == count2

When a float32 Numpy value is squared in the term (x-c)**2, it turns into a float64 value, causing the `T == U` assertion to fail. I think the best way to fix this would be to replace (x-c)**2 with (x-c)*(x-c). This fix would no longer assume the input's ** operator returns the same type.

----------
components: Library (Lib)
messages: 359323
nosy: reed
priority: normal
severity: normal
status: open
title: Assertion failure when calling statistics.variance() on a float32 Numpy array
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Jan  5 02:56:10 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 05 Jan 2020 07:56:10 +0000
Subject: [issue39218] Assertion failure when calling statistics.variance() on
 a float32 Numpy array
In-Reply-To: <1578202492.29.0.981939629191.issue39218@roundup.psfhosted.org>
Message-ID: <1578210970.87.0.0778260047164.issue39218@roundup.psfhosted.org>


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

I think it's more of an implementation artifact of numpy eq definition for float32 and float64 and can possibly break again if (x-c) * (x-c) was also changed to return float64 in future.

----------
nosy: +rhettinger, steven.daprano, taleinat, xtreak

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

From report at bugs.python.org  Sun Jan  5 03:03:42 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 05 Jan 2020 08:03:42 +0000
Subject: [issue39218] Assertion failure when calling statistics.variance() on
 a float32 Numpy array
In-Reply-To: <1578202492.29.0.981939629191.issue39218@roundup.psfhosted.org>
Message-ID: <1578211422.29.0.389855572316.issue39218@roundup.psfhosted.org>


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

Nice analysis and bug report, thank you! That's pretty strange behaviour for float32, but I guess we're stuck with it.

I wonder if the type assertion has outlived its usefulness? I.e. drop the `T == U` part and change the assertion to `assert count == count2` only.

If we removed the failing part of the assertion, and changed the final line to `return (U, total)`, that ought to keep the exact sum but convert to float32 later, rather than float64.

I am inclined to have the stdev of float32 return a float32 is possible. What do you think?

We should check the numpy docs to see what the conversion rules for numpy floats are.

----------

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

From report at bugs.python.org  Sun Jan  5 05:08:08 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 10:08:08 +0000
Subject: [issue39216] ast_opt.c -- missing posonlyargs?
In-Reply-To: <1578187941.0.0.50477954259.issue39216@roundup.psfhosted.org>
Message-ID: <1578218888.68.0.377429481427.issue39216@roundup.psfhosted.org>


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

Hi Anthony,

> not sure if this is intentional or not

Thanks for the catch! Is not intentional. Could you made a PR adding the line?

> Happy to make a patch which adds a line there if someone can help me with the test

We do not have explicit tests for constant folding in the ast level an, in this case, is going to be folded anyway via another code path. For example:

def g():
    def f(x : 3 in {1,2,3}, /): ...
    return f

print(g.__code__.co_consts[2])
frozenset({1, 2, 3})

----------

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

From report at bugs.python.org  Sun Jan  5 05:18:08 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 10:18:08 +0000
Subject: [issue39216] ast_opt.c -- missing posonlyargs?
In-Reply-To: <1578187941.0.0.50477954259.issue39216@roundup.psfhosted.org>
Message-ID: <1578219488.98.0.412207951188.issue39216@roundup.psfhosted.org>


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

If you want to add a test, you could check the dis output for this example:

def make_func(x):
     def f(x : not  (x is x), /): ...

In this case the compiler emits:

  3           0 LOAD_GLOBAL              0 (x)
              2 LOAD_GLOBAL              0 (x)
              4 COMPARE_OP               8 (is)
              6 UNARY_NOT
              8 LOAD_CONST               1 (('x',))
             10 BUILD_CONST_KEY_MAP      1
             12 LOAD_CONST               2 (<code object f at 0x7f3754f71040, file "/home/pablogsal/github/python/master/lel.py", line 3>)
             14 LOAD_CONST               3 ('code.<locals>.f')
             16 MAKE_FUNCTION            4 (annotations)
             18 STORE_FAST               0 (f)

while for 

def make_func(x):
     def f(x : not  (x is x)): .

emits more efficient code (using 'not is' instead of is and UNARY_NOT:

  4          20 LOAD_GLOBAL              0 (x)
             22 LOAD_GLOBAL              0 (x)
             24 COMPARE_OP               9 (is not)
             26 LOAD_CONST               1 (('x',))
             28 BUILD_CONST_KEY_MAP      1
             30 LOAD_CONST               4 (<code object g at 0x7f3754f135f0, file "/home/pablogsal/github/python/master/lel.py", line 4>)
             32 LOAD_CONST               5 ('code.<locals>.g')
             34 MAKE_FUNCTION            4 (annotations)
             36 STORE_FAST               1 (g)
             38 LOAD_CONST               0 (None)
             40 RETURN_VALUE

Adding the missing line makes them do the same.

----------

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

From report at bugs.python.org  Sun Jan  5 05:33:38 2020
From: report at bugs.python.org (Bruce Merry)
Date: Sun, 05 Jan 2020 10:33:38 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1578220418.58.0.804711090463.issue36051@roundup.psfhosted.org>


Bruce Merry <bmerry at gmail.com> added the comment:

I've written a variant of the benchmark in which one thread does joins and the other does unrelated CPU-bound work that doesn't touch memory much. It also didn't show much benefit to thresholds below 512KB. I still want to test things on a server-class CPU, but based on the evidence so far I'm okay with a 1MB threshold.

----------

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

From report at bugs.python.org  Sun Jan  5 05:56:51 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 05 Jan 2020 10:56:51 +0000
Subject: [issue39218] Assertion failure when calling statistics.variance() on
 a float32 Numpy array
In-Reply-To: <1578202492.29.0.981939629191.issue39218@roundup.psfhosted.org>
Message-ID: <1578221811.97.0.50820206116.issue39218@roundup.psfhosted.org>


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

[Karthikeyan]

> can possibly break again if (x-c) * (x-c) was also changed to return float64 in future

I think it's safe to assume that multiplying two NumPy float32's will continue to give a float32 back in the future; NumPy has no reason to give back a different type, and changing this would be a big breaking change.

The big difference between (x-c)**2 and (x-c)*(x-c) in this respect is that the latter is purely an operation on float32 operands, while the former is a mixed-type operation: NumPy sees a binary operation between a float32 and a Python int, and has to figure out a suitable type for the result. The int to float32 conversion is regarded as introducing unacceptable precision loss, so it chooses float64 as an acceptable output type, converts both input operands to that type, and then does the computation.

Some relevant parts of the NumPy docs:

https://docs.scipy.org/doc/numpy/reference/ufuncs.html#casting-rules
https://docs.scipy.org/doc/numpy/reference/generated/numpy.result_type.html

Even for pure Python floats, x*x is a simpler, more accurate, and likely faster operation than x**2. On a typical system, the former (eventually) maps to a hardware floating-point multiplication, which is highly likely to be correctly rounded, while the latter, after conversion of the r.h.s. to a float, maps to a libm pow call. That libm pow call *could* conceivably have a fast/accurate path for a right-hand-side of 2.0, but it could equally conceivably not have such a path.

OTOH, (x-c)*(x-c) repeats the subtraction unnecessarily, but perhaps assignment expressions could rescue us? For example, replace:

    sum((x-c)**2 for x in data)

with:

    sum((y:=(x-c))*y for x in data)

[Steven]

> I am inclined to have the stdev of float32 return a float32 is possible. 

Would that also imply intermediate calculations being performed only with float32, or would intermediate calculations be performed with a more precise type? float32 has small enough precision to run into real accuracy problems with modestly large datasets. For example:

    >>> import numpy as np
    >>> sum(np.ones(10**8, dtype=np.float32), start=np.float32(0))
    16777216.0  # should be 10**8

or, less dramatically:

    >>> sum(np.full(10**6, 1.73, dtype=np.float32), start=np.float32(0)) / 10**6
    1.74242125  # only two accurate significant figures

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

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

From report at bugs.python.org  Sun Jan  5 06:24:56 2020
From: report at bugs.python.org (Mingye Wang)
Date: Sun, 05 Jan 2020 11:24:56 +0000
Subject: [issue28343] Bad encoding alias cp936 -> gbk: euro sign
In-Reply-To: <1475464291.36.0.0934021228231.issue28343@psf.upfronthosting.co.za>
Message-ID: <1578223496.6.0.509311309808.issue28343@roundup.psfhosted.org>


Mingye Wang <arthur200126 at gmail.com> added the comment:

b'\x80'.decode('cp936') is still broken on python 3.7. Working on a PR.

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

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

From report at bugs.python.org  Sun Jan  5 06:33:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2020 11:33:45 +0000
Subject: [issue39219] Fix attributes of syntax errors raized in the tokenizer
Message-ID: <1578224025.61.0.7633610275.issue39219@roundup.psfhosted.org>


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

SyntaxError can be raised at different stages of compiling. In some places the source text is not available and should be read from the file using the file name. Which does not work in case of compiling a string or reading from stdin.

>>> 0z
  File "<stdin>", line 1
    0z
     ^
SyntaxError: invalid syntax
>>> 0xz
  File "<stdin>", line 1
SyntaxError: invalid hexadecimal literal

In the second example above the source line and the caret are absent in REPL.

The proposed PR fixes two errors in raising a SyntaxError in the tokenizer.

1. The text of the source line was not set if an exception was raised in the tokenizer. Since most of these exceptions (with more detailed description) were added in 3.8 I consider this a regressions.

2. The offset attribute was an offset in bytes. Now it is an offset in characters.

It only fixes errors in the tokenizer. There are similar bugs in other parts of the compiler.

This issue is based on the article https://aroberge.blogspot.com/2019/12/a-tiny-python-exception-oddity.html .

----------
components: Interpreter Core
messages: 359331
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix attributes of syntax errors raized in the tokenizer
type: behavior
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Jan  5 07:14:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2020 12:14:38 +0000
Subject: [issue39057] Issues with urllib.request.proxy_bypass_environment
In-Reply-To: <1576439157.59.0.210686585011.issue39057@roundup.psfhosted.org>
Message-ID: <1578226478.94.0.599687500651.issue39057@roundup.psfhosted.org>


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


New changeset 6a265f0d0c0a4b3b8fecf4275d49187a384167f4 by Serhiy Storchaka in branch 'master':
bpo-39057: Fix urllib.request.proxy_bypass_environment(). (GH-17619)
https://github.com/python/cpython/commit/6a265f0d0c0a4b3b8fecf4275d49187a384167f4


----------

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

From report at bugs.python.org  Sun Jan  5 07:14:48 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:14:48 +0000
Subject: [issue39057] Issues with urllib.request.proxy_bypass_environment
In-Reply-To: <1576439157.59.0.210686585011.issue39057@roundup.psfhosted.org>
Message-ID: <1578226488.04.0.280515213222.issue39057@roundup.psfhosted.org>


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


----------
pull_requests: +17256
pull_request: https://github.com/python/cpython/pull/17829

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

From report at bugs.python.org  Sun Jan  5 07:14:55 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:14:55 +0000
Subject: [issue39057] Issues with urllib.request.proxy_bypass_environment
In-Reply-To: <1576439157.59.0.210686585011.issue39057@roundup.psfhosted.org>
Message-ID: <1578226495.22.0.477034095889.issue39057@roundup.psfhosted.org>


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


----------
pull_requests: +17257
pull_request: https://github.com/python/cpython/pull/17830

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

From report at bugs.python.org  Sun Jan  5 07:15:30 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2020 12:15:30 +0000
Subject: [issue39056] Issues with handling the -W option
In-Reply-To: <1576435413.35.0.296920431157.issue39056@roundup.psfhosted.org>
Message-ID: <1578226530.33.0.216677835977.issue39056@roundup.psfhosted.org>


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


New changeset 41ec17e45d54473d32f543396293256f1581e44d by Serhiy Storchaka in branch 'master':
bpo-39056: Fix handling invalid warning category in the -W option. (GH-17618)
https://github.com/python/cpython/commit/41ec17e45d54473d32f543396293256f1581e44d


----------

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

From report at bugs.python.org  Sun Jan  5 07:15:38 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:15:38 +0000
Subject: [issue39056] Issues with handling the -W option
In-Reply-To: <1576435413.35.0.296920431157.issue39056@roundup.psfhosted.org>
Message-ID: <1578226538.78.0.960888120924.issue39056@roundup.psfhosted.org>


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


----------
pull_requests: +17258
pull_request: https://github.com/python/cpython/pull/17831

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

From report at bugs.python.org  Sun Jan  5 07:15:45 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:15:45 +0000
Subject: [issue39056] Issues with handling the -W option
In-Reply-To: <1576435413.35.0.296920431157.issue39056@roundup.psfhosted.org>
Message-ID: <1578226545.87.0.990234031641.issue39056@roundup.psfhosted.org>


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


----------
pull_requests: +17259
pull_request: https://github.com/python/cpython/pull/17832

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

From report at bugs.python.org  Sun Jan  5 07:15:53 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2020 12:15:53 +0000
Subject: [issue39055] base64.b64decode() with validate=True does not raise for
 a trailing \n
In-Reply-To: <1576430488.57.0.854621145537.issue39055@roundup.psfhosted.org>
Message-ID: <1578226553.48.0.490635014388.issue39055@roundup.psfhosted.org>


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


New changeset b19c0d77e6f25ea831ab608c71f15d0d9266c8c4 by Serhiy Storchaka in branch 'master':
bpo-39055: Reject a trailing \n in base64.b64decode() with validate=True. (GH-17616)
https://github.com/python/cpython/commit/b19c0d77e6f25ea831ab608c71f15d0d9266c8c4


----------

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

From report at bugs.python.org  Sun Jan  5 07:16:02 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:16:02 +0000
Subject: [issue39055] base64.b64decode() with validate=True does not raise for
 a trailing \n
In-Reply-To: <1576430488.57.0.854621145537.issue39055@roundup.psfhosted.org>
Message-ID: <1578226562.03.0.928837414598.issue39055@roundup.psfhosted.org>


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


----------
pull_requests: +17260
pull_request: https://github.com/python/cpython/pull/17833

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

From report at bugs.python.org  Sun Jan  5 07:16:08 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:16:08 +0000
Subject: [issue39055] base64.b64decode() with validate=True does not raise for
 a trailing \n
In-Reply-To: <1576430488.57.0.854621145537.issue39055@roundup.psfhosted.org>
Message-ID: <1578226568.8.0.97124498083.issue39055@roundup.psfhosted.org>


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


----------
pull_requests: +17261
pull_request: https://github.com/python/cpython/pull/17834

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

From report at bugs.python.org  Sun Jan  5 07:31:48 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:31:48 +0000
Subject: [issue39057] Issues with urllib.request.proxy_bypass_environment
In-Reply-To: <1576439157.59.0.210686585011.issue39057@roundup.psfhosted.org>
Message-ID: <1578227507.99.0.442363037738.issue39057@roundup.psfhosted.org>


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


New changeset 880a17af7d063fcef225a46b7f4ae35d792b2f11 by Miss Islington (bot) in branch '3.7':
bpo-39057: Fix urllib.request.proxy_bypass_environment(). (GH-17619)
https://github.com/python/cpython/commit/880a17af7d063fcef225a46b7f4ae35d792b2f11


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

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

From report at bugs.python.org  Sun Jan  5 07:32:04 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:32:04 +0000
Subject: [issue39057] Issues with urllib.request.proxy_bypass_environment
In-Reply-To: <1576439157.59.0.210686585011.issue39057@roundup.psfhosted.org>
Message-ID: <1578227524.18.0.207158923059.issue39057@roundup.psfhosted.org>


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


New changeset fc84d501b9d77701cbdd485de45e200bf027c0e9 by Miss Islington (bot) in branch '3.8':
bpo-39057: Fix urllib.request.proxy_bypass_environment(). (GH-17619)
https://github.com/python/cpython/commit/fc84d501b9d77701cbdd485de45e200bf027c0e9


----------

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

From report at bugs.python.org  Sun Jan  5 07:32:48 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:32:48 +0000
Subject: [issue39055] base64.b64decode() with validate=True does not raise for
 a trailing \n
In-Reply-To: <1576430488.57.0.854621145537.issue39055@roundup.psfhosted.org>
Message-ID: <1578227568.57.0.0774523837078.issue39055@roundup.psfhosted.org>


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


New changeset 3bdb2d9daf3ce41b325bd508e3dd29041e85dd1f by Miss Islington (bot) in branch '3.7':
bpo-39055: Reject a trailing \n in base64.b64decode() with validate=True. (GH-17616)
https://github.com/python/cpython/commit/3bdb2d9daf3ce41b325bd508e3dd29041e85dd1f


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

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

From report at bugs.python.org  Sun Jan  5 07:33:11 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:33:11 +0000
Subject: [issue39056] Issues with handling the -W option
In-Reply-To: <1576435413.35.0.296920431157.issue39056@roundup.psfhosted.org>
Message-ID: <1578227591.21.0.927684492129.issue39056@roundup.psfhosted.org>


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


New changeset e1caa49f68dd63b534774aebad0c240143e6fb5d by Miss Islington (bot) in branch '3.8':
bpo-39056: Fix handling invalid warning category in the -W option. (GH-17618)
https://github.com/python/cpython/commit/e1caa49f68dd63b534774aebad0c240143e6fb5d


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

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

From report at bugs.python.org  Sun Jan  5 07:35:02 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:35:02 +0000
Subject: [issue39056] Issues with handling the -W option
In-Reply-To: <1576435413.35.0.296920431157.issue39056@roundup.psfhosted.org>
Message-ID: <1578227702.23.0.0862854210093.issue39056@roundup.psfhosted.org>


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


New changeset 43fbc70360b2a934ea809b2175d7e99031db2df3 by Miss Islington (bot) in branch '3.7':
bpo-39056: Fix handling invalid warning category in the -W option. (GH-17618)
https://github.com/python/cpython/commit/43fbc70360b2a934ea809b2175d7e99031db2df3


----------

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

From report at bugs.python.org  Sun Jan  5 07:36:51 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 12:36:51 +0000
Subject: [issue39055] base64.b64decode() with validate=True does not raise for
 a trailing \n
In-Reply-To: <1576430488.57.0.854621145537.issue39055@roundup.psfhosted.org>
Message-ID: <1578227811.84.0.743324224172.issue39055@roundup.psfhosted.org>


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


New changeset 34aa3e71dc52c1a31336302905b9ac011a310412 by Miss Islington (bot) in branch '3.8':
bpo-39055: Reject a trailing \n in base64.b64decode() with validate=True. (GH-17616)
https://github.com/python/cpython/commit/34aa3e71dc52c1a31336302905b9ac011a310412


----------

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

From report at bugs.python.org  Sun Jan  5 08:26:51 2020
From: report at bugs.python.org (Carl Friedrich Bolz-Tereick)
Date: Sun, 05 Jan 2020 13:26:51 +0000
Subject: [issue39220] constant folding affects annotations despite 'from
 __future__ import annotations'
Message-ID: <1578230811.94.0.250306045254.issue39220@roundup.psfhosted.org>


New submission from Carl Friedrich Bolz-Tereick <cfbolz at gmx.de>:

PEP 563 interacts in weird ways with constant folding. running the following code:

```
from __future__ import annotations

def f(a: 5 + 7) -> a ** 39:
    return 12

print(f.__annotations__)
```

I would expect this output:

```
{'a': '5 + 7', 'return': 'a ** 39'}
```

But I get:


```
{'a': '12', 'return': 'a ** 39'}
```

----------
components: Interpreter Core
files: x.py
messages: 359341
nosy: Carl.Friedrich.Bolz
priority: normal
severity: normal
status: open
title: constant folding affects annotations despite 'from __future__ import annotations'
versions: Python 3.7
Added file: https://bugs.python.org/file48827/x.py

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

From report at bugs.python.org  Sun Jan  5 08:28:20 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 05 Jan 2020 13:28:20 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1578230900.2.0.172237186235.issue1635741@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Jan  5 08:30:21 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 05 Jan 2020 13:30:21 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1578231021.45.0.491845160391.issue1635741@roundup.psfhosted.org>


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

One part of this issue is that all C extensions of the stdlib should be updated to implement the PEP 489 "Multi-phase extension module initialization".
> I try to port _json extension module to multiphase initialization module, but the baseline(using victor's code) in my vm not changed~

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

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

From report at bugs.python.org  Sun Jan  5 08:33:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2020 13:33:12 +0000
Subject: [issue39057] Issues with urllib.request.proxy_bypass_environment
In-Reply-To: <1576439157.59.0.210686585011.issue39057@roundup.psfhosted.org>
Message-ID: <1578231192.18.0.392306410699.issue39057@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Jan  5 08:33:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2020 13:33:25 +0000
Subject: [issue39056] Issues with handling the -W option
In-Reply-To: <1576435413.35.0.296920431157.issue39056@roundup.psfhosted.org>
Message-ID: <1578231205.04.0.463286738927.issue39056@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Jan  5 08:33:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2020 13:33:45 +0000
Subject: [issue39055] base64.b64decode() with validate=True does not raise for
 a trailing \n
In-Reply-To: <1576430488.57.0.854621145537.issue39055@roundup.psfhosted.org>
Message-ID: <1578231225.42.0.341053228673.issue39055@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Jan  5 08:41:23 2020
From: report at bugs.python.org (Andrew Aladjev)
Date: Sun, 05 Jan 2020 13:41:23 +0000
Subject: [issue39221] Cross compiled python installed wrong version of
 lib2to3/Grammar pickle
Message-ID: <1578231683.23.0.24612692977.issue39221@roundup.psfhosted.org>


New submission from Andrew Aladjev <aladjev.andrew at gmail.com>:

Please see the following gentoo bug https://bugs.gentoo.org/704816

https://github.com/python/cpython/blob/master/Lib/lib2to3/pgen2/driver.py#L110

> head + tail + ".".join(map(str, sys.version_info)) + ".pickle"

I've tried "print(sys.version_info)" during compilation and received:
> sys.version_info(major=3, minor=6, micro=9, releaselevel='final', serial=0)

"sys.version_info" is not the target python version, this is the version of python that is running compilation. This variable needs to be replace with something like "sys.target_python_version".

This issue looks simple but I can't fix it by myself. Please assign this issue to core developer. We need to find all places where "sys.version_info" is used as target python version during compilation and replace it.

----------
components: Library (Lib)
messages: 359343
nosy: puchenyaka
priority: normal
severity: normal
status: open
title: Cross compiled python installed wrong version of lib2to3/Grammar pickle
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Jan  5 08:44:50 2020
From: report at bugs.python.org (Andrew Aladjev)
Date: Sun, 05 Jan 2020 13:44:50 +0000
Subject: [issue39221] Cross compiled python installed wrong version of
 lib2to3/Grammar pickle
In-Reply-To: <1578231683.23.0.24612692977.issue39221@roundup.psfhosted.org>
Message-ID: <1578231890.18.0.138575297403.issue39221@roundup.psfhosted.org>


Andrew Aladjev <aladjev.andrew at gmail.com> added the comment:

This is build.log:

https://gist.githubusercontent.com/andrew-aladev/f36e8e754278e4fad50ff13238326f7a/raw/245a72e8bd0fb3dc6e4185ec757b2d3ab59d5861/gistfile1.txt

We can see that python installed "Grammar3.6.9.final.0.pickle" instead of "Grammar3.6.10.final.0.pickle"

----------

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

From report at bugs.python.org  Sun Jan  5 09:14:47 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 05 Jan 2020 14:14:47 +0000
Subject: [issue39197] argparse: title and description for mutually exclusive
 arg groups
In-Reply-To: <1577995665.78.0.21290537011.issue39197@roundup.psfhosted.org>
Message-ID: <1578233687.65.0.0174647573155.issue39197@roundup.psfhosted.org>


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

Do you have user case for it?

_ArgumentGroup have the `title` attribute, so  _MutuallyExclusiveGroup add same attribute is not a big probleam(if user really need it).

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

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

From report at bugs.python.org  Sun Jan  5 09:43:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2020 14:43:22 +0000
Subject: [issue32856] Optimize the `for y in [x]` idiom in comprehensions
In-Reply-To: <1518770483.24.0.467229070634.issue32856@psf.upfronthosting.co.za>
Message-ID: <1578235402.63.0.127267382012.issue32856@roundup.psfhosted.org>


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

I want to merge PR 16814 if there are no objections.

----------

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

From report at bugs.python.org  Sun Jan  5 09:45:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2020 14:45:52 +0000
Subject: [issue37685] Fix equality checks for some types
In-Reply-To: <1564088866.66.0.720895226226.issue37685@roundup.psfhosted.org>
Message-ID: <1578235552.75.0.0527826507225.issue37685@roundup.psfhosted.org>


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


----------
pull_requests: +17263
pull_request: https://github.com/python/cpython/pull/17836

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

From report at bugs.python.org  Sun Jan  5 09:49:42 2020
From: report at bugs.python.org (Bruce Merry)
Date: Sun, 05 Jan 2020 14:49:42 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1578235782.06.0.24984306581.issue36051@roundup.psfhosted.org>


Bruce Merry <bmerry at gmail.com> added the comment:

I ran the test on a Xeon machine (Skylake-XP) and it also looks like performance is only improved from 1MB up (somewhat to my surprise, given how poor single-threaded memcpy performance is on that machine). So I've updated the pull request with that threshold.

----------

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

From report at bugs.python.org  Sun Jan  5 09:56:50 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 05 Jan 2020 14:56:50 +0000
Subject: [issue39216] ast_opt.c -- missing posonlyargs?
In-Reply-To: <1578187941.0.0.50477954259.issue39216@roundup.psfhosted.org>
Message-ID: <1578236210.05.0.838437490725.issue39216@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


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

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

From report at bugs.python.org  Sun Jan  5 09:58:32 2020
From: report at bugs.python.org (Florian Brucker)
Date: Sun, 05 Jan 2020 14:58:32 +0000
Subject: [issue39222] unittest.mock.Mock.parent is broken or undocumented
Message-ID: <1578236312.03.0.58171840403.issue39222@roundup.psfhosted.org>


New submission from Florian Brucker <python-bugs at florianbrucker.de>:

The "parent" attribute of unittest.mock.Mock is either broken or undocumented.

For example, on Python 3.7.4:

>>> from unittest.mock import Mock
>>> m = Mock(x=1, parent=2)
>>> m.x
1
>>> m.parent
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/unittest/mock.py", line 659, in __repr__
    name = self._extract_mock_name()
  File "/usr/local/lib/python3.7/unittest/mock.py", line 638, in _extract_mock_name
    _name_list.append(_parent._mock_new_name + dot)
AttributeError: 'int' object has no attribute '_mock_new_name'
>>> parent = Mock()
>>> child = Mock(parent=parent)
>>> child.parent is parent
False

I stumbled upon this while trying to mock an object that has a "parent" attribute.

>From the documentation I understand that mocks have built-in parents. However, the documentation never mentions the "parent" attribute specifically, so I always assumed that the built-in parent-child relationship was handled using private or name-mangled attributes. And since the "parent" attribute is not mentioned in the docs, I assumed I could set it by passing an additional kwarg to Mock.

I would have expected one of the following, in order of personal preference:

a) That a private or name-mangled attribute is used for the built-in parent-child relationship, so that I can mock objects which themselves have a "parent" attribute

b) That the special meaning of the "parent" attribute is documented, and that trying to set it directly (via the constructor or via attribute assignment, and without going through attach_mock) triggers a warning.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 359348
nosy: docs at python, florian.brucker
priority: normal
severity: normal
status: open
title: unittest.mock.Mock.parent is broken or undocumented
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Jan  5 10:34:58 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 05 Jan 2020 15:34:58 +0000
Subject: [issue39222] unittest.mock.Mock.parent is broken or undocumented
In-Reply-To: <1578236312.03.0.58171840403.issue39222@roundup.psfhosted.org>
Message-ID: <1578238498.87.0.188909763163.issue39222@roundup.psfhosted.org>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Sun Jan  5 10:37:22 2020
From: report at bugs.python.org (Shane)
Date: Sun, 05 Jan 2020 15:37:22 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578238642.8.0.346398013957.issue39211@roundup.psfhosted.org>


Shane <shanesmith4 at gmail.com> added the comment:

A small update:

Using the direct invocation:

> python -m http.server 8000
Serving HTTP on :: port 8080 (http://[::]:8080/) ...

Is NOT accessible at the following addresses:
http://[::]:8080/  # most surprising, because this is where it tells you to go
http://<my_ip_address>:8080/  # this was the Python <= 3.7 behavior, as I used it anyhow

But it IS accessible at the following addresses:
http://[::1]:8080/
http://localhost:8080/


There may be others I don't know about.  I recognize that my difficulties likely arise from a lack of familiarity with internet protocols, as this isn't something I use with any kind of regularity.  But I do think it's possible (and desirable) for the method to be as casual-friendly as it was in Python 3.7.

Specifically, the direct invocation tells the user they can go to http://[::]:8080/, which they cannot.  They CAN go to http://[::1]:8080/.  Should this instead be the message returned on direct invocation?

So far as I can tell, this is still a behavior change, as the old behavior was accessible from your IP address and therefore visible to other computers on the network (I assume localhost is not).  But it would at least do what it says on the tin.

----------

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

From report at bugs.python.org  Sun Jan  5 10:51:54 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 05 Jan 2020 15:51:54 +0000
Subject: [issue39223] Fold constant slicing with slices
Message-ID: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>


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

>>> def g(): "abcde"[2:4]
... 
>>> g.__code__.co_consts
(None, 'abcde', 2, 4)

to 

>>> def g(): "abcde"[2:4]
... 
>>> g.__code__.co_consts
(None, 'cd')

(I have a patch)

----------
components: Interpreter Core
messages: 359350
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: Fold constant slicing with slices
versions: Python 3.9

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

From report at bugs.python.org  Sun Jan  5 10:57:02 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 05 Jan 2020 15:57:02 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578239822.8.0.121602106395.issue39223@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


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

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

From report at bugs.python.org  Sun Jan  5 11:24:06 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Jan 2020 16:24:06 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578241446.19.0.189746024599.issue39152@roundup.psfhosted.org>


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


New changeset 5ea7bb25e3b192d6c49a49c9e3b316f8559602aa by Terry Jan Reedy in branch 'master':
bpo-39152: add missing ttk.Scale.configure return value (GH-17815)
https://github.com/python/cpython/commit/5ea7bb25e3b192d6c49a49c9e3b316f8559602aa


----------

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

From report at bugs.python.org  Sun Jan  5 11:24:15 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 16:24:15 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578241455.25.0.94042422524.issue39152@roundup.psfhosted.org>


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


----------
pull_requests: +17266
pull_request: https://github.com/python/cpython/pull/17839

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

From report at bugs.python.org  Sun Jan  5 11:34:19 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 05 Jan 2020 16:34:19 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578242059.94.0.327771103147.issue39223@roundup.psfhosted.org>


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

Does this occur often enough that it's worth the added code?

----------
nosy: +eric.smith

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

From report at bugs.python.org  Sun Jan  5 11:48:59 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 16:48:59 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578242939.16.0.631766967176.issue39152@roundup.psfhosted.org>


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


----------
pull_requests: +17267
pull_request: https://github.com/python/cpython/pull/17840

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

From report at bugs.python.org  Sun Jan  5 11:49:52 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 16:49:52 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578242992.01.0.218262671915.issue39152@roundup.psfhosted.org>


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


New changeset 6234301bb56a9b388a1c3bf51169a2762ea09172 by Miss Islington (bot) in branch '3.7':
bpo-39152: add missing ttk.Scale.configure return value (GH-17815)
https://github.com/python/cpython/commit/6234301bb56a9b388a1c3bf51169a2762ea09172


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

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

From report at bugs.python.org  Sun Jan  5 12:04:52 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 17:04:52 +0000
Subject: [issue39216] ast_opt.c -- missing posonlyargs?
In-Reply-To: <1578187941.0.0.50477954259.issue39216@roundup.psfhosted.org>
Message-ID: <1578243892.69.0.0300668337888.issue39216@roundup.psfhosted.org>


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


----------
pull_requests: +17268
pull_request: https://github.com/python/cpython/pull/17841

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

From report at bugs.python.org  Sun Jan  5 12:05:50 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 17:05:50 +0000
Subject: [issue39216] ast_opt.c -- missing posonlyargs?
In-Reply-To: <1578187941.0.0.50477954259.issue39216@roundup.psfhosted.org>
Message-ID: <1578243950.61.0.490280983792.issue39216@roundup.psfhosted.org>


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

Thanks again for the fix and the investigation!

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

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

From report at bugs.python.org  Sun Jan  5 12:06:23 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 05 Jan 2020 17:06:23 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578243983.93.0.00305616229377.issue39211@roundup.psfhosted.org>


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

It's the addition of flags=socket.AI_PASSIVE on Lib/http/server.py:1233 that's causing this. I think this also breaks for IPv4 sockets.

----------
components: +Library (Lib)
keywords: +3.8regression
nosy: +SilentGhost
stage:  -> needs patch

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

From report at bugs.python.org  Sun Jan  5 12:07:33 2020
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 05 Jan 2020 17:07:33 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1578244053.7.0.603942575705.issue34480@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

HTMLParser is supposed to follow the HTML5 standard, and never raise an error.

For the example in the first comment ("<![hi world]>"), the steps should be:

* https://html.spec.whatwg.org/multipage/parsing.html#data-state:tag-open-state
* https://html.spec.whatwg.org/multipage/parsing.html#tag-open-state:markup-declaration-open-state
* https://html.spec.whatwg.org/multipage/parsing.html#markup-declaration-open-state:bogus-comment-state
* https://html.spec.whatwg.org/multipage/parsing.html#bogus-comment-state

I agree that the error should be fixed by setting `match` to None, and a test case that triggers the UnboundLocalError (before the fix) should be added as well (what provided by Karthikeyan looks good).

However, it also seems wrong that HTMLParser ends up calling self.error() through  Lib/_markupbase.py ParserBase after HTMLParser.error() and all the calls to it have been removed.  _markupbase.py is internal, so it should be safe to remove ParserBase.error() and the code that calls it as suggested in #31844 (and possibly to merge _markupbase into html.parser too).  Even if this is done and the call to self.error() is removed from ParserBase.parse_marked_section(), `match` still needs to be set to None (either in the `else` branch or before the `if/elif` block).

----------

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

From report at bugs.python.org  Sun Jan  5 12:07:36 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 17:07:36 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578244056.64.0.94850858573.issue39152@roundup.psfhosted.org>


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


New changeset 636a850ed81cf9b8feed523f277b1538bfc5230b by Miss Islington (bot) in branch '3.8':
bpo-39152: add missing ttk.Scale.configure return value (GH-17815)
https://github.com/python/cpython/commit/636a850ed81cf9b8feed523f277b1538bfc5230b


----------

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

From report at bugs.python.org  Sun Jan  5 12:16:36 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 17:16:36 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578244596.93.0.954642280192.issue39223@roundup.psfhosted.org>


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

I am with Eric. Why would anyone write:


"abcde"[2:4]

Instead of just

cd

?

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

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

From report at bugs.python.org  Sun Jan  5 12:17:40 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 17:17:40 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578244660.37.0.988949959649.issue39223@roundup.psfhosted.org>


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

Specially because you need to do the mental calculation to know what the indexes are for the letters you want, and at that point you better write that string anyways, no?

----------

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

From report at bugs.python.org  Sun Jan  5 12:19:13 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 05 Jan 2020 17:19:13 +0000
Subject: [issue39152] Faulty override of tkinter.Misc.configure in
 tkinter.ttk.Scale.configure
In-Reply-To: <1577624733.91.0.369906281789.issue39152@roundup.psfhosted.org>
Message-ID: <1578244753.32.0.170673636766.issue39152@roundup.psfhosted.org>


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


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Jan  5 12:20:27 2020
From: report at bugs.python.org (Lee Collins)
Date: Sun, 05 Jan 2020 17:20:27 +0000
Subject: [issue39174] unicodedata.normalize failing with NFD and NFKD for some
 characters in Python3
In-Reply-To: <1577816551.99.0.153382211706.issue39174@roundup.psfhosted.org>
Message-ID: <1578244827.18.0.487387354593.issue39174@roundup.psfhosted.org>


Lee Collins <lcollins at netflix.com> added the comment:

I did some more investigation by running cat on a file with the decomposed characters and saw that the output was composed. So, this does look like a problem with the Mac OS terminal. It can be resolved as 3rd party

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Sun Jan  5 12:20:45 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 05 Jan 2020 17:20:45 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578244845.19.0.511176986396.issue39223@roundup.psfhosted.org>


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

We already have a folding operation for Index access ("abcde"[2]) and there was a todo (left by @methane I guess) about supporting other slicings. I think this would look inconsistent if one is support and not the other one.

----------

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

From report at bugs.python.org  Sun Jan  5 12:23:57 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 05 Jan 2020 17:23:57 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1578245037.17.0.711866759875.issue34480@roundup.psfhosted.org>


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

> _markupbase.py is internal, so it should be safe to remove
> ParserBase.error() and the code that calls it as suggested in #31844

Should I reopen https://github.com/python/cpython/pull/8562 then?

----------

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

From report at bugs.python.org  Sun Jan  5 12:30:57 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 17:30:57 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578245457.55.0.840451103893.issue39200@roundup.psfhosted.org>


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


New changeset 4b66fa6ce9c37e70b55af220d0e07368319de803 by Pablo Galindo in branch 'master':
bpo-39200: Correct the error message for range() empty constructor (GH-17813)
https://github.com/python/cpython/commit/4b66fa6ce9c37e70b55af220d0e07368319de803


----------

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

From report at bugs.python.org  Sun Jan  5 12:52:31 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 05 Jan 2020 17:52:31 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578246751.3.0.507381195773.issue39223@roundup.psfhosted.org>


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

Then I'd suggest removing the optimization for "abcde"[2], too. I've never seen this in real code, and I can't come up with a scenario where it would be performance critical. Remember, one of the goals for CPython is to be reasonable readable, not maximally tricky.

Could you point to the code (or ideally the commit) with methane's comment?

I'm not trying to be a jerk, though. I do appreciate your patch, I just think it's not appropriate for CPython.

----------

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

From report at bugs.python.org  Sun Jan  5 12:56:25 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 05 Jan 2020 17:56:25 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578246985.73.0.762816422101.issue39223@roundup.psfhosted.org>


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

> Then I'd suggest removing the optimization for "abcde"[2], too. I've never seen this in real code, and I can't come up with a scenario where it would be performance critical. Remember, one of the goals for CPython is to be reasonable readable, not maximally tricky.

I dont think this patch will decrease readability and make code complex.

> Could you point to the code (or ideally the commit) with methane's comment?
https://github.com/python/cpython/blob/master/Python/ast_opt.c#L319 (PR 2858)

----------

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

From report at bugs.python.org  Sun Jan  5 13:08:21 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 18:08:21 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578247701.54.0.615855269937.issue39223@roundup.psfhosted.org>


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

I was reading the pull request and I have to say that I find using a switch instead of a very crowded "if" ward a bit more readable.

I would be +0 on this case.

----------

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

From report at bugs.python.org  Sun Jan  5 13:08:29 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 05 Jan 2020 18:08:29 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578247709.75.0.501344816601.issue39223@roundup.psfhosted.org>


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

I've scanned stdlib, django and flask and no usage so far. There is one in the test (which basically verifies behavior of slice) and one in the argument clinic which passes the newline for a multiline string. 

cpython/Tools/clinic/clinic.py:1185
cpython/Lib/test/test_descr.py:3789

----------

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

From report at bugs.python.org  Sun Jan  5 13:18:31 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 18:18:31 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578248311.37.0.572211040379.issue39223@roundup.psfhosted.org>


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

The one in cpython/Tools/clinic/clinic.py:1185 is sort of an anti-pattern as it should be using 

'''\
Something something
'''

instead of skipping the newline.

----------

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

From report at bugs.python.org  Sun Jan  5 13:22:42 2020
From: report at bugs.python.org (Giovanni Lombardo)
Date: Sun, 05 Jan 2020 18:22:42 +0000
Subject: [issue31485] Tkinter widget.unbind(sequence,
 funcid) unbind all bindings
In-Reply-To: <1505483834.38.0.808110743528.issue31485@psf.upfronthosting.co.za>
Message-ID: <1578248562.19.0.155651411235.issue31485@roundup.psfhosted.org>


Giovanni Lombardo <g.lombardo at protonmail.com> added the comment:

I propose the below fix:

```
    def unbind(self, sequence, funcid=None):
        """Unbind for this widget for event SEQUENCE  the
        function identified with FUNCID."""
        bound = ''
        if funcid:
            self.deletecommand(funcid)
            funcs = self.tk.call('bind', self._w, sequence, None).split('\n')
            bound = '\n'.join([f for f in funcs if not f.startswith('if {{"[{0}'.format(funcid))])
        self.tk.call('bind', self._w, sequence, bound)
```

----------

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

From report at bugs.python.org  Sun Jan  5 13:33:27 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 05 Jan 2020 18:33:27 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578249207.16.0.495911532817.issue39223@roundup.psfhosted.org>


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

It looks like we have some usage for normal indexing (not this PR, the original optimization);

cpython/cpython/Lib/base64.py:382
cpython/cpython/Lib/base64.py:382
cpython/cpython/Lib/base64.py:393
cpython/cpython/Lib/base64.py:397
cpython/cpython/Lib/pickle.py:306
cpython/cpython/Lib/pickle.py:1291
cpython/cpython/Lib/glob.py:155
cpython/cpython/Lib/test/test_mmap.py:59
cpython/cpython/Lib/test/test_mmap.py:63
cpython/cpython/Lib/test/test_mmap.py:574
cpython/cpython/Lib/test/test_codecs.py:2317
cpython/cpython/Lib/test/test_codecs.py:2323
cpython/cpython/Lib/test/test_contextlib.py:1025
cpython/cpython/Lib/test/test_struct.py:645

----------

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

From report at bugs.python.org  Sun Jan  5 13:54:07 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 18:54:07 +0000
Subject: [issue39220] constant folding affects annotations despite 'from
 __future__ import annotations'
In-Reply-To: <1578230811.94.0.250306045254.issue39220@roundup.psfhosted.org>
Message-ID: <1578250447.77.0.362574482883.issue39220@roundup.psfhosted.org>


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


----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Sun Jan  5 13:54:21 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 05 Jan 2020 18:54:21 +0000
Subject: [issue39220] constant folding affects annotations despite 'from
 __future__ import annotations'
In-Reply-To: <1578230811.94.0.250306045254.issue39220@roundup.psfhosted.org>
Message-ID: <1578250461.03.0.321143432972.issue39220@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya -lukasz.langa

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

From report at bugs.python.org  Sun Jan  5 13:54:37 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 05 Jan 2020 18:54:37 +0000
Subject: [issue39220] constant folding affects annotations despite 'from
 __future__ import annotations'
In-Reply-To: <1578230811.94.0.250306045254.issue39220@roundup.psfhosted.org>
Message-ID: <1578250477.92.0.821931143862.issue39220@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Sun Jan  5 13:55:17 2020
From: report at bugs.python.org (Daniel Farley)
Date: Sun, 05 Jan 2020 18:55:17 +0000
Subject: [issue39224] HTTPConnection.timeout None support
Message-ID: <1578250517.62.0.0768078724722.issue39224@roundup.psfhosted.org>


New submission from Daniel Farley <danfarley93 at gmail.com>:

HTTPConnection's `timeout` argument is passed down to `socket.settimeout()` which supports `None` and puts the socket in blocking mode. This isn't documented on the `http.client` page. Otherwise it should not be allowed.

----------
assignee: docs at python
components: Documentation
messages: 359371
nosy: Daniel Farley, docs at python
priority: normal
severity: normal
status: open
title: HTTPConnection.timeout None support
type: behavior

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

From report at bugs.python.org  Sun Jan  5 13:57:00 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 05 Jan 2020 18:57:00 +0000
Subject: [issue39221] Cross compiled python installed wrong version of
 lib2to3/Grammar pickle
In-Reply-To: <1578231683.23.0.24612692977.issue39221@roundup.psfhosted.org>
Message-ID: <1578250620.99.0.093876059233.issue39221@roundup.psfhosted.org>


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


----------
nosy: +doko

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

From report at bugs.python.org  Sun Jan  5 13:57:53 2020
From: report at bugs.python.org (Daniel Farley)
Date: Sun, 05 Jan 2020 18:57:53 +0000
Subject: [issue39224] HTTPConnection.timeout None support
In-Reply-To: <1578250517.62.0.0768078724722.issue39224@roundup.psfhosted.org>
Message-ID: <1578250673.36.0.111154480582.issue39224@roundup.psfhosted.org>


Change by Daniel Farley <danfarley93 at gmail.com>:


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

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

From report at bugs.python.org  Sun Jan  5 13:59:41 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 18:59:41 +0000
Subject: [issue39220] constant folding affects annotations despite 'from
 __future__ import annotations'
In-Reply-To: <1578230811.94.0.250306045254.issue39220@roundup.psfhosted.org>
Message-ID: <1578250781.19.0.72034317726.issue39220@roundup.psfhosted.org>


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

?ukasz, should we disable AST optimizations in annotations if "from __future__ import annotations" is used?

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

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

From report at bugs.python.org  Sun Jan  5 14:04:06 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 19:04:06 +0000
Subject: [issue39220] constant folding affects annotations despite 'from
 __future__ import annotations'
In-Reply-To: <1578230811.94.0.250306045254.issue39220@roundup.psfhosted.org>
Message-ID: <1578251046.9.0.245133263421.issue39220@roundup.psfhosted.org>


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

Yo be honest, this would add a lot of complexity as "from __future__ import annotations" is a compiler directive (CO_FUTURE_ANNOTATIONS) and bringing this to the AST level would be somehow disrupting. 

I would be -1 to disable AST optimizations in annotations.

----------

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

From report at bugs.python.org  Sun Jan  5 14:10:27 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 05 Jan 2020 19:10:27 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578251427.68.0.212658460372.issue39211@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

First, a quick primer in IP:

- Addresses are written as XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX, but any single span of zeros can be written as ::, so `::` is all zeros and `::1` is the same as 0000:0000:0000:0000:0000:0000:0000:0001.
- ::1 is the local host (the some machine as where the code is running), equivalent to 127.0.0.1 in IPv4.
- To listen on all interfaces, the socket library expects the system to bind to 0.0.0.0 (IPv4) or :: (IPv6).
- When specified in a URL, an IPv6 address must be wrapped in [] to distinguish the `:` characters from the port separator. For example, http://[::1]:8000/ specifies connect to localhost over IPv6 on port 8000.
- If the system supports dual-stack IPv4 over IPv6, all IPv4 addresses are mapped to a specific IPv6 subnet, so binding/listening on IPv6 often allows a client to connect to IPv4.
- Even if the server is listening on all interfaces (0.0.0.0/::), the client must specify an internet address that will reach that address.

As a result of this last point, it's not possible for a server like http.server to reliably know what address a client would be able to use to connect to the server. That is, if the server is bound on all interfaces, a local client could connect over localhost/127.0.0.1/::1 (assuming that interface exist, which it doesn't sometimes) or to another address assigned  by the host, e.g. 2601:547:501:6ba:d1e6:300d:7e83:6b6f. A client on another host, however, would not be able to use localhost to connect to the server. It _must_ use an address that's both assigned to the server's host, bound by the server, and routeable to/from the client (i.e. not blocked by a firewall).

Prior to Python 3.8, the default behavior was to bind to all interfaces on IPv4 only, which was unnecessarily limiting, but was subject to the same unexpected behavior:

```
draft $ python3.7 -m http.server                                                                                                                                                                             
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
```

The URL there `http://0.0.0.0:8000/` has the same failure mode as the one described above. One cannot browse to that address, but must replace `0.0.0.0` with `localhost` or `127.0.0.1` (to connect from localhost) or replace with a routable address to connect from another host. The only difference is that with Python 3.8, now IPv6 is honored.

Note if one passes `localhost` or `127.0.0.1` or `::1` as the bind parameter, the URL indicated would work:

```
draft $ python -m http.server --bind localhost                                                                                                                                                               
Serving HTTP on ::1 port 8000 (http://[::1]:8000/) ...
```

Since it's not possible in general to supply the URL a client would need to connect to the server, it's difficult to reliably provide a useful URL.

Some web servers do apply [a heuristic](https://github.com/jaraco/portend/blob/754c37046d86d178d20faa8dbfe910482d79bdff/portend.py#L27-L46) that translates "all addresses" to a "localhost" address, and Python stdlib could implement that heuristic.

> On 3.7.X I was able to use it as described in the docs and it would default to whatever IP address was available.

That behavior should be the same, except that it should now bind to both IPv6 and IPv4. If you previously ran without any parameters, it would bind to all interfaces on IPv4. Now it binds on all interfaces on IPv6, which should be backward compatible in dual-stack environments like Windows. You just have to translate `[::]` to `localhost` instead of translating `0.0.0.0` to `localhost`.


When I tested your findings on macOS, everything worked as I expected. I launched the server with `python -m http.server`, and the site could be reached on http://localhost:8000/ and http://127.0.0.1:8000 and http://[::1]:8000/. Nevertheless, when I tried the same thing on my Windows machine, I got a different outcome. The server bound to [::0] but was unreachable on http://127.0.0.1:8000.

That was unexpected, and I'll try to ascertain why the dual-stack behavior isn't working as I'd expect.

----------
nosy:  -SilentGhost
stage: needs patch -> 

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

From report at bugs.python.org  Sun Jan  5 14:18:13 2020
From: report at bugs.python.org (Andrew Aladjev)
Date: Sun, 05 Jan 2020 19:18:13 +0000
Subject: [issue39221] Cross compiled python installed wrong version of
 lib2to3/Grammar pickle
In-Reply-To: <1578231683.23.0.24612692977.issue39221@roundup.psfhosted.org>
Message-ID: <1578251893.9.0.992883132476.issue39221@roundup.psfhosted.org>


Andrew Aladjev <aladjev.andrew at gmail.com> added the comment:

For now I've created a workaround - just removed python version from pickle generator. For my current container it works perfect.

----------
keywords: +patch
Added file: https://bugs.python.org/file48828/remove_python_version_from_pickle.patch

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

From report at bugs.python.org  Sun Jan  5 14:36:12 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 05 Jan 2020 19:36:12 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578252972.4.0.407272226708.issue39211@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> It's the addition of flags=socket.AI_PASSIVE on Lib/http/server.py:1233 that's causing this.

Can you elaborate? What is it causing?

I can see that flag was added in https://github.com/python/cpython/pull/11767/commits/62dbe55c9d88c75868399de9d86bcd947e23951c for the purpose of:

> indicate to get the wildcard address (all interfaces).

I don't recall beyond that why I went that route.

I can see in https://github.com/cherrypy/cherrypy/issues/871, CherryPy had to add [this code](https://github.com/cherrypy/cheroot/blob/420d50c4167be89ee4f5841a493fbd2bb929982e/cheroot/server.py#L1946-L1962) to support dual-stack operation. I suspect that's also what Python needs here (in addition to a test that binding on :: responds on 127.0.0.1).

----------

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

From report at bugs.python.org  Sun Jan  5 15:01:08 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 05 Jan 2020 20:01:08 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578254468.89.0.654069632317.issue39211@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Indeed, if I apply this patch:

```
diff --git a/Lib/http/server.py b/Lib/http/server.py
index 47a4fcf9a6..de995ae4b9 100644
--- a/Lib/http/server.py
+++ b/Lib/http/server.py
@@ -1246,6 +1246,11 @@ def test(HandlerClass=BaseHTTPRequestHandler,
     """
     ServerClass.address_family, addr = _get_best_family(bind, port)
 
+    def server_bind(self, orig=ServerClass.server_bind):
+        self.socket.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_V6ONLY, 0)
+        return orig(self)
+    ServerClass.server_bind = server_bind
+
     HandlerClass.protocol_version = protocol
     with ServerClass(addr, HandlerClass) as httpd:
         host, port = httpd.socket.getsockname()[:2]
```

And then run `python -m http.server`, it binds to `::` but responds on `127.0.0.1` on Windows:

```
~ # python -m http.server
Serving HTTP on :: port 8000 (http://[::]:8000/) ... 
::ffff:127.0.0.1 - - [05/Jan/2020 14:48:09] "GET / HTTP/1.1" 200 - 
```

I think the solution is to add a patch similar to that until Python has a socketserver that supports dual-stack binding. See related issues issue25667, issue20215, issue36208, issue17561, and issue38907.

In fact, since issue38907 captures more concretely what I believe is the main issue here, I'm going to use that issue to address the concern. If Windows is able to bind dual-stack to IPv6/IPv4, I believe that would address the compatibility concern raised herein.

I'm going to mark this as a duplicate, but if you believe there is another issue at play here, please don't hesitate to re-open or comment and I can.

----------
resolution:  -> duplicate
status: open -> pending
superseder:  -> Add IPv6 Dual-Stack control for http.server

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

From report at bugs.python.org  Sun Jan  5 15:03:41 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 05 Jan 2020 20:03:41 +0000
Subject: [issue38907] http.server (command) fails to bind dual-stack on Windows
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1578254621.11.0.438653630364.issue38907@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In issue39211, I've done a good deal of investigation on this issue and confirmed your findings - on Windows, the server fails to bind dual stack on Windows, but instead binds IPV6ONLY. That needs to be fixed such that the default is to bind dual-stack. Adding dual-stack control is a new feature and should be considered separately.

----------
nosy: +jaraco
title: Add IPv6 Dual-Stack control for http.server -> http.server (command) fails to bind dual-stack on Windows

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

From report at bugs.python.org  Sun Jan  5 15:07:36 2020
From: report at bugs.python.org (Shane)
Date: Sun, 05 Jan 2020 20:07:36 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578254856.59.0.311302642832.issue39211@roundup.psfhosted.org>


Shane <shanesmith4 at gmail.com> added the comment:

Jason, thank you for the primer.

> Nevertheless, when I tried the same thing on my Windows machine, I got a different outcome. The server bound to [::0] but was unreachable on http://127.0.0.1:8000.

Perhaps it's an issue with IPv4 addresses in general for Python 3.8 on Windows when they are not directly bound during invocation of the server.  I used to be able to reach the server with http://<my_ipv4_address>:8080/ (this was my initial surprise), but now this behavior doesn't work for me.  However, on further testing http://<my_ipv6_address>:8080/ DOES work.

----------
status: pending -> open

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

From report at bugs.python.org  Sun Jan  5 15:16:18 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2020 20:16:18 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578255378.35.0.0287230930482.issue39223@roundup.psfhosted.org>


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

The optimization for constant indexes is handy for things like b'A'[0]. I do not know cases for constant slices of constant strings.

Even if there are cases, we need to prove that they are common enough. The compiler does not perform all possible constant foldings, it does it only to support common cases like 24*60*60 or 2**32-1.

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

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

From report at bugs.python.org  Sun Jan  5 15:37:33 2020
From: report at bugs.python.org (Reed)
Date: Sun, 05 Jan 2020 20:37:33 +0000
Subject: [issue39218] Assertion failure when calling statistics.variance() on
 a float32 Numpy array
In-Reply-To: <1578202492.29.0.981939629191.issue39218@roundup.psfhosted.org>
Message-ID: <1578256653.54.0.488351288618.issue39218@roundup.psfhosted.org>


Reed <readuw at gmail.com> added the comment:

Thank you all for the comments! Either using (x-c)*(x-c), or removing the assertion and changing the final line to `return (U, total)`, seem reasonable. I slightly prefer the latter case, due to Mark's comments about x*x being faster and simpler than x**2. But I am not an expert on this.

> I am inclined to have the stdev of float32 return a float32 is possible. What do you think?

Agreed.

> OTOH, (x-c)*(x-c) repeats the subtraction unnecessarily, but perhaps assignment expressions could rescue us?

Yeah, we should avoid repeating the subtraction. Another method of doing so is to define a square function. For example:

    def square(y):
        return y*y
    sum(square(x-c) for x in data)

> Would that also imply intermediate calculations being performed only with float32, or would intermediate calculations be performed with a more precise type?

Currently, statistics.py computes sums in infinite precision (https://github.com/python/cpython/blob/422ed16fb846eec0b5b2a4eb3a978c9862615665/Lib/statistics.py#L123) for any type. The multiplications (and exponents if we go that route) would still be float32.

----------

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

From report at bugs.python.org  Sun Jan  5 15:50:13 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 05 Jan 2020 20:50:13 +0000
Subject: [issue33255] json.dumps has different behaviour if encoding='utf-8'
 or encoding='utf8'
In-Reply-To: <1523352074.24.0.682650639539.issue33255@psf.upfronthosting.co.za>
Message-ID: <1578257413.47.0.579477734551.issue33255@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Jan  5 15:51:58 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 05 Jan 2020 20:51:58 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578257518.06.0.221433571102.issue39223@roundup.psfhosted.org>


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

> Even if there are cases, we need to prove that they are common enough

I don't think cases for an extended slicing are common enough. In addition to stdlib, Django and flask (checked by Batuhan) I checked many popular 3rd party packages and there is not an occurrence of the pattern.

----------

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

From report at bugs.python.org  Sun Jan  5 16:30:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2020 21:30:52 +0000
Subject: [issue39223] Fold constant slicing with slices
In-Reply-To: <1578239514.69.0.32377155521.issue39223@roundup.psfhosted.org>
Message-ID: <1578259852.14.0.172982983414.issue39223@roundup.psfhosted.org>


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

Then I suggest to focus on optimizing real code.

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

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

From report at bugs.python.org  Sun Jan  5 17:18:09 2020
From: report at bugs.python.org (Reuven Lerner)
Date: Sun, 05 Jan 2020 22:18:09 +0000
Subject: [issue39225] Python should warn when a global/local has the same name
 as a builtin
Message-ID: <1578262689.16.0.500995659902.issue39225@roundup.psfhosted.org>


New submission from Reuven Lerner <reuven at lerner.co.il>:

Newcomers to Python are often frustrated and surprised when they define variables such as "sum" and "list", only to discover that they've masked access builtins of the same name.

External code checkers do help, but those don't work in Jupyter or other non-IDE environments.

It would be nice if defining a global/local with the same name as a builtin would generate a warning.  For example:

list = [10, 20, 30]
RedefinedBuiltinWarning: "list" is a builtin, and should normally not be redefined. 

I'm sure that the wording could use a lot of work, but something like this would do wonders to help newbies, who encounter this all the time. Experienced developers are surprised that these terms aren't reserved words.

----------
components: Interpreter Core
messages: 359384
nosy: reuven
priority: normal
severity: normal
status: open
title: Python should warn when a global/local has the same name as a builtin

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

From report at bugs.python.org  Sun Jan  5 17:32:26 2020
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 05 Jan 2020 22:32:26 +0000
Subject: [issue39212] Show qualified function name when giving arguments error
In-Reply-To: <1578163945.77.0.403027118696.issue39212@roundup.psfhosted.org>
Message-ID: <1578263546.29.0.437829137339.issue39212@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

Here is a short IPython session:

In [1]: class Foo:                                                         
   ...:     def __init__(self, x):                                         
   ...:         pass                                                       
   ...:                                                                    
                                                                           
In [2]: Foo(7, 8)                                                          
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-2-efa33418c6bb> in <module>                                 
----> 1 Foo(7, 8)                                                          
                                                                           
TypeError: __init__() takes 2 positional arguments but 3 were given        

As you can see, it's pretty simple to get this exception text, so I'm not sure why you didn't get that text. This is on Python 3.8.1.

Regarding you saying it's more annoying than useful: Especially for methods such as `__init__`, it's often difficult to understand which class is being instantiated, especially in a complex codebase. It happened to me last week at work, and even with a debugger and being an experienced Python developer, it took me a few minutes to figure out which `__init__` method was being called.

----------

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

From report at bugs.python.org  Sun Jan  5 17:39:46 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 22:39:46 +0000
Subject: [issue39130] Dict is reversable from v3.8 and should say that in the
 doc
Message-ID: <1578263986.1.0.861594582146.issue39130@roundup.psfhosted.org>


New submission from miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


New changeset 94d9cfc4ed9dd3c4a3a359bc194b4dc3f6ba63eb by Miss Islington (bot) (Khalid Mammadov) in branch 'master':
bpo-39130: Dict reversed was added in v3.8 so should say in the doc as well (GH-17694)
https://github.com/python/cpython/commit/94d9cfc4ed9dd3c4a3a359bc194b4dc3f6ba63eb


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

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

From report at bugs.python.org  Sun Jan  5 17:39:51 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 22:39:51 +0000
Subject: [issue39130] Dict is reversable from v3.8 and should say that in the
 doc
In-Reply-To: <1578263986.1.0.861594582146.issue39130@roundup.psfhosted.org>
Message-ID: <1578263991.25.0.727877448538.issue39130@roundup.psfhosted.org>


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


----------
pull_requests: +17270
pull_request: https://github.com/python/cpython/pull/17848

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

From report at bugs.python.org  Sun Jan  5 17:45:38 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 05 Jan 2020 22:45:38 +0000
Subject: [issue39130] Dict is reversable from v3.8 and should say that in the
 doc
In-Reply-To: <1578263986.1.0.861594582146.issue39130@roundup.psfhosted.org>
Message-ID: <1578264338.72.0.48617447682.issue39130@roundup.psfhosted.org>


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


New changeset 89947881ac36324148fab75190af453dc09fd862 by Miss Islington (bot) in branch '3.8':
bpo-39130: Dict reversed was added in v3.8 so should say in the doc as well (GH-17694)
https://github.com/python/cpython/commit/89947881ac36324148fab75190af453dc09fd862


----------

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

From report at bugs.python.org  Sun Jan  5 17:50:13 2020
From: report at bugs.python.org (=?utf-8?q?Antonio_V=C3=A1zquez_Blanco?=)
Date: Sun, 05 Jan 2020 22:50:13 +0000
Subject: [issue39226] venv does not include pythonXX.lib
Message-ID: <1578264613.69.0.856144088862.issue39226@roundup.psfhosted.org>


New submission from Antonio V?zquez Blanco <antoniovazquezblanco at gmail.com>:

I've tryed to install mod_wsgi using pip lately in a venv. This installation process fails with a message about a missing venv\scripts\libs\python38.lib file as reported in https://github.com/GrahamDumpleton/mod_wsgi/issues/506

It seems that this file used to be included in virtual environments but the behaviour has changed. This library seems to be a dependency for some modules, shouldn't it be included in the virtual environment? Is this behaviour change desired? If so, how should modules link to python.lib?

Thanks in advance

----------
components: Library (Lib)
messages: 359388
nosy: Antonio V?zquez Blanco
priority: normal
severity: normal
status: open
title: venv does not include pythonXX.lib
type: behavior

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

From report at bugs.python.org  Sun Jan  5 17:52:47 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 05 Jan 2020 22:52:47 +0000
Subject: [issue39225] Python should warn when a global/local has the same name
 as a builtin
In-Reply-To: <1578262689.16.0.500995659902.issue39225@roundup.psfhosted.org>
Message-ID: <1578264767.89.0.368011413432.issue39225@roundup.psfhosted.org>


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

On the other hand, this would generate a lot of warnings for users of libraries, who aren't able to do anything about it. I've got tons of existing code that uses the names of builtins as locals, to no harm. And as builtins are added, new warnings would pop up.

A linter is really the best way to handle this. Maybe Jupyter could add its own warning.

----------
nosy: +eric.smith

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

From report at bugs.python.org  Sun Jan  5 19:09:41 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 06 Jan 2020 00:09:41 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578269381.68.0.382326486612.issue38623@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +brett.cannon
versions:  -Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Jan  5 19:27:17 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 06 Jan 2020 00:27:17 +0000
Subject: [issue25872] multithreading traceback KeyError when modifying file
In-Reply-To: <1450200064.35.0.872448112145.issue25872@psf.upfronthosting.co.za>
Message-ID: <1578270437.04.0.308759002734.issue25872@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

As @xtreak said, this looks like it was fixed for Python 3 and was only an issue for 2.7, so I'm closing the issue.

----------
nosy: +cheryl.sabella
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Jan  5 19:50:41 2020
From: report at bugs.python.org (Michael Graczyk)
Date: Mon, 06 Jan 2020 00:50:41 +0000
Subject: [issue25872] multithreading traceback KeyError when modifying file
In-Reply-To: <1450200064.35.0.872448112145.issue25872@psf.upfronthosting.co.za>
Message-ID: <1578271841.42.0.403212906262.issue25872@roundup.psfhosted.org>


Michael Graczyk <Michael at mgraczyk.com> added the comment:

This issue still exists in Python 3. The repro just needs to be changed so that the threads are actually started.

- map(lambda t: t.start(), threads)
- map(lambda t: t.join(), threads)
+ [t.start() for t in threads]
+ [t.join() for t in threads]

My fix is linked.

----------
nosy: +Michael Graczyk

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

From report at bugs.python.org  Sun Jan  5 21:11:41 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jan 2020 02:11:41 +0000
Subject: [issue25667] Supply dual-stack (IPv4/IPv6) socket bind routine
In-Reply-To: <1447939973.83.0.965937708444.issue25667@psf.upfronthosting.co.za>
Message-ID: <1578276701.26.0.503444223819.issue25667@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


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

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

From report at bugs.python.org  Sun Jan  5 21:11:41 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jan 2020 02:11:41 +0000
Subject: [issue20215] socketserver.TCPServer can not listen IPv6 address
In-Reply-To: <1389319382.42.0.481013787618.issue20215@psf.upfronthosting.co.za>
Message-ID: <1578276701.36.0.271384999487.issue20215@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +17274
pull_request: https://github.com/python/cpython/pull/17851

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

From report at bugs.python.org  Sun Jan  5 21:11:41 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jan 2020 02:11:41 +0000
Subject: [issue38907] http.server (command) fails to bind dual-stack on Windows
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1578276701.15.0.721149880576.issue38907@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +17272
pull_request: https://github.com/python/cpython/pull/17851

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

From report at bugs.python.org  Sun Jan  5 21:17:31 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jan 2020 02:17:31 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578277051.17.0.982611324402.issue39211@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Other than addressing issue38907, is there anything else to be done here? In GH-17851, I've proposed a surgical fix to address the issue with IPv4 being unbound on Windows.

----------

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

From report at bugs.python.org  Sun Jan  5 21:18:32 2020
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Mon, 06 Jan 2020 02:18:32 +0000
Subject: [issue39227] OverflowError in len(range(2**63))
Message-ID: <1578277112.33.0.0446121238087.issue39227@roundup.psfhosted.org>


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

The value for `len` internally passes through an `ssize_t`, which means that it raises OverflowError for (very) large collections.

This is admittedly only possible with collections such as `range` that do not store all their elements in memory, but it would still be nice to have `len(range(n)) == n` without caveats.

This was found via a teaching example and is now tracked in my repo of property-based tests for CPython:
https://github.com/rsokl/Learning_Python/pull/125
https://github.com/Zac-HD/stdlib-property-tests/blob/bb46996ca4500381ba09a8cd430caaddd71910bc/tests.py#L28-L34

Related to https://bugs.python.org/issue26423, but it's still present in the development branches for 3.7, 3.8, and 3.9; and instead of a wrong result it's an error (which is better!).

----------
components: Interpreter Core
messages: 359394
nosy: Zac Hatfield-Dodds
priority: normal
severity: normal
status: open
title: OverflowError in len(range(2**63))
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/issue39227>
_______________________________________

From report at bugs.python.org  Sun Jan  5 21:34:37 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jan 2020 02:34:37 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1572119300.64.0.0138111717141.issue38597@roundup.psfhosted.org>
Message-ID: <1578278077.81.0.947035260658.issue38597@roundup.psfhosted.org>


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

I haven't looked into _why_ yet, but the first PYD I grabbed from the GitHub link above has had the CRT statically linked. This is not the default (or it should not be), because when we made it the default this exact issue occurred :)

If somehow the default linking mode in distutils has changed, we should fix that. If it is being overridden by Setuptools or Cython then we should get those projects fixed.

Stefan/Paul - do Cython or Setuptools override compiler/linker settings like this at all? Most likely it's the /MT vs /MD option

----------
nosy: +p-ganssle, scoder

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

From report at bugs.python.org  Sun Jan  5 21:40:16 2020
From: report at bugs.python.org (Shane)
Date: Mon, 06 Jan 2020 02:40:16 +0000
Subject: [issue39211] Change in http.server default IP behavior?
In-Reply-To: <1578162394.57.0.362691529673.issue39211@roundup.psfhosted.org>
Message-ID: <1578278416.38.0.938112817689.issue39211@roundup.psfhosted.org>


Shane <shanesmith4 at gmail.com> added the comment:

Based on my understanding, your fix should do it.

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

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

From report at bugs.python.org  Sun Jan  5 22:21:30 2020
From: report at bugs.python.org (Manish)
Date: Mon, 06 Jan 2020 03:21:30 +0000
Subject: [issue30717] Add unicode grapheme cluster break algorithm
In-Reply-To: <1497986122.28.0.540580196076.issue30717@psf.upfronthosting.co.za>
Message-ID: <1578280890.0.0.889384912462.issue30717@roundup.psfhosted.org>


Manish <manishsmail at gmail.com> added the comment:

Hi,

Unicodey person here, I'm involved in Unicode itself and also maintain an implementation of this particular spec[1].


So, firstly,

> "a?".center(width=5, fillchar=".")

If you're trying to do terminal width stuff, extended grapheme clusters *will not* solve the problem for you. There is no algorithm specified in Unicode that does this, because this is font dependent. Extended grapheme clusters are better than code points for this, however, and will not ever produce *worse* results.


It's fine to expose this, but it's worth adding caveats.

Also, yes, please do not expose a direct indexing function. Aside from almost all Unicode algorithms being streaming algorithms and thus inefficient to index directly, needing to directly index a grapheme cluster is almost always a sign that you are making a mistake.

> Yes. I clearly don't want this PR to be interpreted as "we're needing ICU". ICU provides much much more than what I'm willing to provide. My goal here is just to "fix" how the python's standard library iterates over characters. Noting more, nothing less.

I think it would be a mistake to make the stdlib use this for most notions of what a "character" is, as I said this notion is also inaccurate. Having an iterator library somewhere that you can use and compose is great, changing the internal workings of string operations would be a major change, and not entirely productive.

There's only one language I can think of that uses extended grapheme clusters as its default notion of "character": Swift. Swift is largely designed for UI stuff, and it makes sense in this context. This is also baked in very deeply to the language (e.g. their Character class is a thin wrapper around String, since grapheme clusters can be arbitrarily large). You'd need a pretty major paradigm shift for python to make a similar change, and it doesn't make as much sense for python in the first place.

Starting off with a library published to pypi makes sense to me.


 [1]: https://github.com/unicode-rs/unicode-segmentation/

----------
nosy: +Manishearth

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

From report at bugs.python.org  Sun Jan  5 22:25:02 2020
From: report at bugs.python.org (Manish)
Date: Mon, 06 Jan 2020 03:25:02 +0000
Subject: [issue30717] Add unicode grapheme cluster break algorithm
In-Reply-To: <1497986122.28.0.540580196076.issue30717@psf.upfronthosting.co.za>
Message-ID: <1578281102.89.0.303472369147.issue30717@roundup.psfhosted.org>


Manish <manishsmail at gmail.com> added the comment:

Oh, also, if y'all are fine with binding to Rust (through a C ABI) I'd love to help y'all use unicode-segmentation, which is much less work that pulling in ICU. Otherwise if y'all have implementation questions I can answer them. This spec is kinda tricky to implement efficiently, but it's not super hard.

----------

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

From report at bugs.python.org  Sun Jan  5 22:32:26 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jan 2020 03:32:26 +0000
Subject: [issue38907] http.server (command) fails to bind dual-stack on Windows
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1578281546.56.0.389976112715.issue38907@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset ee94bdb0598f9bc47d6a49e58fffc97aa617be96 by Jason R. Coombs in branch 'master':
bpo-38907: In http.server script, restore binding to IPv4 on Windows. (GH-17851)
https://github.com/python/cpython/commit/ee94bdb0598f9bc47d6a49e58fffc97aa617be96


----------

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

From report at bugs.python.org  Sun Jan  5 22:32:34 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 03:32:34 +0000
Subject: [issue38907] http.server (command) fails to bind dual-stack on Windows
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1578281554.73.0.447646909503.issue38907@roundup.psfhosted.org>


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


----------
pull_requests: +17275
pull_request: https://github.com/python/cpython/pull/17854

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

From report at bugs.python.org  Sun Jan  5 23:14:25 2020
From: report at bugs.python.org (daniel hahler)
Date: Mon, 06 Jan 2020 04:14:25 +0000
Subject: [issue39228] traceback.FrameSummary does not handle exceptions from
 `repr()`
Message-ID: <1578284065.37.0.657086816746.issue39228@roundup.psfhosted.org>


New submission from daniel hahler <python-bugs at thequod.de>:

Exceptions within `__repr__` methods of captured locals
(e.g. via the `capture_locals` argument of `TracebackException`) are not handled:

```
import traceback


class CrashingRepr:
    def __repr__(self):
        raise RuntimeError("crash")


traceback.FrameSummary("fname", 1, "name", locals={"crash": CrashingRepr()})
```

Result:
```
Traceback (most recent call last):
  File "test_framesummary_repr.py", line 9, in <module>
    traceback.FrameSummary("fname", 1, "name", locals={"crash": CrashingRepr()})
  File "?/pyenv/3.8.0/lib/python3.8/traceback.py", line 260, in __init__
    self.locals = {k: repr(v) for k, v in locals.items()} if locals else None
  File "?/pyenv/3.8.0/lib/python3.8/traceback.py", line 260, in <dictcomp>
    self.locals = {k: repr(v) for k, v in locals.items()} if locals else None
  File "test_framesummary_repr.py", line 6, in __repr__
    raise RuntimeError("crash")
RuntimeError: crash
```

The following patch would fix this:

```diff
diff --git i/Lib/traceback.py w/Lib/traceback.py
index 7a4c8e19f9..eed7082db4 100644
--- i/Lib/traceback.py
+++ w/Lib/traceback.py
 class FrameSummary:
     """A single frame from a traceback.

@@ -257,7 +265,17 @@ def __init__(self, filename, lineno, name, *, lookup_line=True,
         self._line = line
         if lookup_line:
             self.line
-        self.locals = {k: repr(v) for k, v in locals.items()} if locals else None
+        if locals:
+            self.locals = {}
+            for k, v in locals.items():
+                try:
+                    self.locals[k] = repr(v)
+                except (KeyboardInterrupt, SystemExit):
+                    raise
+                except BaseException as exc:
+                    self.locals[k] = f"<unrepresentable repr ({exc})>"
+        else:
+            self.locals = None

     def __eq__(self, other):
         if isinstance(other, FrameSummary):

```

----------
components: Library (Lib)
messages: 359400
nosy: blueyed
priority: normal
severity: normal
status: open
title: traceback.FrameSummary does not handle exceptions from `repr()`
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/issue39228>
_______________________________________

From report at bugs.python.org  Sun Jan  5 23:23:10 2020
From: report at bugs.python.org (daniel hahler)
Date: Mon, 06 Jan 2020 04:23:10 +0000
Subject: [issue39228] traceback.FrameSummary does not handle exceptions from
 `repr()`
In-Reply-To: <1578284065.37.0.657086816746.issue39228@roundup.psfhosted.org>
Message-ID: <1578284590.07.0.727466805006.issue39228@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


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

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

From report at bugs.python.org  Mon Jan  6 00:38:30 2020
From: report at bugs.python.org (Rafael Fontenelle)
Date: Mon, 06 Jan 2020 05:38:30 +0000
Subject: [issue39229] library/functions.rst causes translated builds to fail
Message-ID: <1578289110.04.0.11997957012.issue39229@roundup.psfhosted.org>


New submission from Rafael Fontenelle <rffontenelle at gmail.com>:

Documentation file library/functions.rst has a syntax issue that when building documentation with warnings as errors, the following message appears:

cpython/Doc/library/functions.rst:: WARNING: inconsistent term references in translated message. original: [], translated: [':ref:`evento de auditoria <auditing>`']

After several testing, it seems that what is causing this is librar/functions.rst's line 795 not having a reference ":ref:`auditing event <auditing>`".


Steps to reproduce the issue:

1. git clone --depth 1 https://github.com/python/cpython

2. mkdir -p locale/pt_BR/LC_MESSAGES
3. git clone --depth 1 https://github.com/python/python-docs-pt-br locale/pt_BR/LC_MESSAGES

4. cd locale/pt_BR/LC_MESSAGES

# This takes about 40 minutes (can be ignored for outdated po files with more unrelated syntax errors) 
5. tx pull --force --language pt_BR --parallel

6. cd ../../..

7. cd cpython/Doc/

8. make venv

9. make html                                \
    SPHINXOPTS='-q --keep-going -jauto      \
        -D locale_dirs=../../locale         \
        -D language=pt_BR                   \
        -D gettext_compact=0                \
        -D latex_engine=xelatex             \
        -D latex_elements.inputenc=         \
        -D latex_elements.fontenc='

10. Look for library/functions.rst "WARNING" error message between the output.

----------
assignee: docs at python
components: Documentation
messages: 359401
nosy: docs at python, rffontenelle
priority: normal
severity: normal
status: open
title: library/functions.rst causes translated builds to fail
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Mon Jan  6 00:41:15 2020
From: report at bugs.python.org (Rafael Fontenelle)
Date: Mon, 06 Jan 2020 05:41:15 +0000
Subject: [issue39229] library/functions.rst causes translated builds to fail
In-Reply-To: <1578289110.04.0.11997957012.issue39229@roundup.psfhosted.org>
Message-ID: <1578289275.97.0.494828203544.issue39229@roundup.psfhosted.org>


Change by Rafael Fontenelle <rffontenelle at gmail.com>:


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

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

From report at bugs.python.org  Mon Jan  6 00:56:44 2020
From: report at bugs.python.org (Vinay Keerthi)
Date: Mon, 06 Jan 2020 05:56:44 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578290204.91.0.825501804652.issue38623@roundup.psfhosted.org>


Vinay Keerthi <ktvkvinaykeerthi+python at gmail.com> added the comment:

Just chiming in my opinion, the site-packages directory is also dependent on venv, correct? So would explaining where it is at a global install level be much use? Or do you mean explaining where site-packages is even for a venv?


I could take this up, if some agrees that jr needs doing.

----------
nosy: +stonecharioteer

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

From report at bugs.python.org  Mon Jan  6 01:07:56 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Jan 2020 06:07:56 +0000
Subject: [issue39229] library/functions.rst causes translated builds to fail
In-Reply-To: <1578289110.04.0.11997957012.issue39229@roundup.psfhosted.org>
Message-ID: <1578290876.8.0.53905340852.issue39229@roundup.psfhosted.org>


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


----------
nosy: +mdk

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

From report at bugs.python.org  Mon Jan  6 01:17:15 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 06 Jan 2020 06:17:15 +0000
Subject: [issue38597] C Extension import limit
In-Reply-To: <1578278077.81.0.947035260658.issue38597@roundup.psfhosted.org>
Message-ID: <155d211e-7294-e9d5-af45-62f420db0369@behnel.de>


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

Cython doesn't interfere with the C compiler setup in any way, that's left
to distutils/setuptools (and the user).

----------

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

From report at bugs.python.org  Mon Jan  6 01:48:02 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 06 Jan 2020 06:48:02 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578293282.52.0.727006871867.issue38623@roundup.psfhosted.org>


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

There is a document about it in Doc/library/site.rst already.

I'm not sure this should be documented in the tutorial.

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

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

From report at bugs.python.org  Mon Jan  6 02:25:09 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 06 Jan 2020 07:25:09 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578295509.37.0.00127781968368.issue38623@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +17278
pull_request: https://github.com/python/cpython/pull/17858

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

From report at bugs.python.org  Mon Jan  6 02:39:32 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 06 Jan 2020 07:39:32 +0000
Subject: [issue39227] OverflowError in len(range(2**63))
In-Reply-To: <1578277112.33.0.0446121238087.issue39227@roundup.psfhosted.org>
Message-ID: <1578296372.85.0.863208672627.issue39227@roundup.psfhosted.org>


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

Duplicate of #12159?

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

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

From report at bugs.python.org  Mon Jan  6 02:45:02 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 06 Jan 2020 07:45:02 +0000
Subject: [issue39227] OverflowError in len(range(2**63))
In-Reply-To: <1578277112.33.0.0446121238087.issue39227@roundup.psfhosted.org>
Message-ID: <1578296702.16.0.323494188179.issue39227@roundup.psfhosted.org>


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

(See also #21444)

----------

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

From report at bugs.python.org  Mon Jan  6 03:23:53 2020
From: report at bugs.python.org (Stefan Schukat)
Date: Mon, 06 Jan 2020 08:23:53 +0000
Subject: [issue18930] os.spawnXX functions terminates process if second
 argument is empty list
In-Reply-To: <1378378354.78.0.544374922966.issue18930@psf.upfronthosting.co.za>
Message-ID: <1578299033.36.0.736558059379.issue18930@roundup.psfhosted.org>


Stefan Schukat <sschukat at dspace.de> added the comment:

@Batuhan the error does not appear anymore in at least Python 3.6.1
>>> import os
>>> nPath = os.path.join(os.environ["windir"], "notepad.exe")
>>> os.spawnv(os.P_NOWAIT, nPath, []) # or os.spawnv(os.P_NOWAIT, nPath, [], {})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: spawnv() arg 2 cannot be empty

----------

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

From report at bugs.python.org  Mon Jan  6 03:44:47 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 06 Jan 2020 08:44:47 +0000
Subject: [issue30717] Add unicode grapheme cluster break algorithm
In-Reply-To: <1578280890.0.0.889384912462.issue30717@roundup.psfhosted.org>
Message-ID: <20200106084438.GA839@ando.pearwood.info>


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

> I think it would be a mistake to make the stdlib use this for most 
> notions of what a "character" is, as I said this notion is also 
> inaccurate. Having an iterator library somewhere that you can use and 
> compose is great, changing the internal workings of string operations 
> would be a major change, and not entirely productive.

Agreed. 

I won't pretend to be able to predict what Python 5.0 will bring *wink* 
but there's too much history around the "code point = character" notion 
for the language to change now.

If the language can expose a grapheme iterator, then people can 
experiment with grapheme-based APIs in libraries.

(By grapheme I mean "extended grapheme cluster", but that's a mouthful. 
Sorry linguists.)

What do you think of these as a set of grapheme primitives?

(1) is_grapheme_break(string, i)

Return True if a grapheme break would occur *before* string[i].

(2) graphemes(string, start=0, end=len(string))

Iterate over graphemes in string[start:end].

(3) graphemes_reversed(string, start=0, end=len(string))

Iterate over graphemes in reverse order.

I *think* is_grapheme_break would be enough for people to implement 
their own versions of graphemes and graphemes_reversed. Here's an 
untested version:

    def graphemes(string, start, end):
        cluster = []
        for i in range(start, end):
            c = string[i]
            if is_grapheme_break(string, i):
                if i != start:
                    # don't yield the empty cluster at Start Of Text
                    yield ''.join(cluster)
                cluster = [c]
            else:
                cluster.append(c)
        if cluster:
            yield ''.join(cluster)

Regarding is_grapheme_break, if I understand the note here:

https://www.unicode.org/reports/tr29/#Testing

one never needs to look at more than two adjacent code points to tell 
whether or not a grapheme break will occur between them, so this ought 
to be pretty efficient. At worst, it needs to look at string[i-1] and 
string[i], if they exist.

----------

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

From report at bugs.python.org  Mon Jan  6 04:13:05 2020
From: report at bugs.python.org (Manish)
Date: Mon, 06 Jan 2020 09:13:05 +0000
Subject: [issue30717] Add unicode grapheme cluster break algorithm
In-Reply-To: <1497986122.28.0.540580196076.issue30717@psf.upfronthosting.co.za>
Message-ID: <1578301985.47.0.653194398748.issue30717@roundup.psfhosted.org>


Manish <manishsmail at gmail.com> added the comment:

> one never needs to look at more than two adjacent code points to tell 
whether or not a grapheme break will occur between them, so this ought 
to be pretty efficient. 


That note is outdated (and has been outdated since Unicode 9). The regional indicator rules (GB12 and GB13) and the emoji rule (GB11) require arbitrary lookbehind (though thankfully not arbitrary lookahead).

I think the ideal API surface is an iterator and nothing else. Everything else can be derived from the iterator. It's theoretically possible to expose an is_grapheme_break that's faster than just iterating -- look at the code in unicode-segmentation's _reverse_ iterator to see how -- but it's going to be tricky to get right. Building the iterator on top of is_grapheme_break is not a good idea.

----------

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

From report at bugs.python.org  Mon Jan  6 04:30:34 2020
From: report at bugs.python.org (Joongi Kim)
Date: Mon, 06 Jan 2020 09:30:34 +0000
Subject: [issue38599] Deprecate creation of asyncio object when the loop is
 not running
In-Reply-To: <1572160085.79.0.39835517746.issue38599@roundup.psfhosted.org>
Message-ID: <1578303034.2.0.549826906004.issue38599@roundup.psfhosted.org>


Joongi Kim <me at daybreaker.info> added the comment:

It is also generating deprecation warning:

> /opt/python/3.8.0/lib/python3.8/asyncio/queues.py:48: DeprecationWarning: The loop argument is deprecated since Python 3.8, and scheduled for removal in Python 3.10.
>   self._finished = locks.Event(loop=loop)

----------
nosy: +achimnol

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

From report at bugs.python.org  Mon Jan  6 04:32:48 2020
From: report at bugs.python.org (Peter Bittner)
Date: Mon, 06 Jan 2020 09:32:48 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578303168.07.0.959398134663.issue38623@roundup.psfhosted.org>


Peter Bittner <peter.bittner at gmx.net> added the comment:

There is a specific question this change attempts to answer: "Where is the module I imported located in the file system?"

I suspect this comes up a lot because developers want to inspect or mess with installed modules, add debug output and the like, to understand some of their development issues better.

The site module documentation explains the details.[3] The paragraph the change adds links to that documentation. That should be sufficient (for a tutorial); other technical details probably fit well in the document being linked to.

[3] https://docs.python.org/3/library/site.html#site.getusersitepackages

I tried to keep it concise, adding value with a quick glance over the `site` module features that relate to the module paths topic.

----------

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

From report at bugs.python.org  Mon Jan  6 04:50:58 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 06 Jan 2020 09:50:58 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578304258.19.0.208498049725.issue38623@roundup.psfhosted.org>


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

> There is a specific question this change attempts to answer: "Where is the module I imported located in the file system?"

So `print(the_module.__file__)` is better answer.  (or `pip list -v` if the module is third party package installed via pip).

`python -m site` doesn't tell you where the imported module came from.



> [3] https://docs.python.org/3/library/site.html#site.getusersitepackages

After merging PR 17858, you can use :ref:`site-commandline` for cross reference.

----------

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

From report at bugs.python.org  Mon Jan  6 04:51:00 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 06 Jan 2020 09:51:00 +0000
Subject: [issue39212] Show qualified function name when giving arguments error
In-Reply-To: <1578263546.29.0.437829137339.issue39212@roundup.psfhosted.org>
Message-ID: <20200106095052.GB839@ando.pearwood.info>


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

On Sun, Jan 05, 2020 at 10:32:26PM +0000, Ram Rachum wrote:
[...]
> TypeError: __init__() takes 2 positional arguments but 3 were given        
> 
> As you can see, it's pretty simple to get this exception text, so I'm not sure why you didn't get that text. 

But I *did* get that text. I'm asking how you got the *different* text 
which you gave in your initial request.

Firstly, you stated that you got the fully-qualified exception type:

    builtins.TypeError

rather than just TypeError, which was my question. How did you get the 
fully-qualified exception class?

Secondly you quoted the error message:

    __init__() takes 1 positional argument but 2 were given

which is what I get in 3.5 using `def __init__(self)`, but in 3.8 it 
gives a different message "MyClass() takes no arguments".

I'm not worried about the error message discrepency, since that's 
irrelevant to your enhancement request, and easily explained if you were 
quoting from an older version of Python. But I don't know how you got 
the `builtins.TypeError` fully-qualified part. That is the part I'm 
asking about.

> Regarding you saying it's more annoying than useful: Especially for 
> methods such as `__init__`, it's often difficult to understand which 
> class is being instantiated, especially in a complex codebase.

I agree with you that there are occasions where this could be difficult. 
Apart from the "no source code" case, I can see that might be the case 
if the failing line is a complex expression like this:

    do_things(Spam(arg)[Eggs(None)] + Cheese(Aardvark(thingy)))

and you don't know which of Spam, Eggs, Cheese or Aardvark has failed. 
Or in an expression like this:

    lookup_class['some key'](arg)

where the source is only an indirect reference to the class you want.

But in my experience, the great bulk of calls to classes (apart from 
simple "atomic" values like int, float, str, etc) stand alone:

    obj = MyClass(arg)

and there is no difficulty in telling which class has the problem.

In my experience, I would say > 90% easy cases and < 10% tricky cases. 
(YMMV.)

So in my opinion, and I recognise that you may disagree, this is only of 
benefit in a minority of cases. For the majority of cases, it will only 
be additional noise in the message that adds nothing that wasn't already 
obvious from the source line.

And in particular, beginners are often intimidated by error messages, 
and the longer the error message, the more they are intimidated. In that 
case, `TypeError: __init__ ...` is shorter and therefore less scary than 
`builtins.TypeError: package.some_module.MyClass.__init__ ...`.

So I'm not disputing that this will be useful *sometimes*. I'm just 
trying to weigh up the cons of longer, more complex error messages 
with redundant information versus the occasional cases where the 
information is helpful.

----------

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

From report at bugs.python.org  Mon Jan  6 05:13:32 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 10:13:32 +0000
Subject: [issue39209] Crash on REPL mode with long text copy and paste
In-Reply-To: <1578148172.19.0.147940927734.issue39209@roundup.psfhosted.org>
Message-ID: <1578305612.79.0.410842750887.issue39209@roundup.psfhosted.org>


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

I bisected this to this commit:

995d9b92979768125ced4da3a56f755bcdf80f6e is the first bad commit
commit 995d9b92979768125ced4da3a56f755bcdf80f6e
Author: Anthony Sottile <asottile at umich.edu>
Date:   Sat Jan 12 20:05:13 2019 -0800

    bpo-16806: Fix `lineno` and `col_offset` for multi-line string tokens (GH-10021)

 Lib/test/test_ast.py                               | 19 +++++++++++++
 Lib/test/test_fstring.py                           | 32 +++++++++-------------
 Lib/test/test_opcodes.py                           |  2 +-
 Lib/test/test_string_literals.py                   |  8 +++---
 Misc/ACKS                                          |  1 +
 .../2018-10-20-18-05-58.bpo-16806.zr3A9N.rst       |  1 +
 Parser/parsetok.c                                  | 15 ++++++++--
 Parser/tokenizer.c                                 |  7 +++++
 Parser/tokenizer.h                                 |  5 ++++
 Python/ast.c                                       | 10 +++++--
 Python/importlib.h                                 | 16 +++++------
 Python/importlib_external.h                        | 18 ++++++------
 Python/importlib_zipimport.h                       |  8 +++---
 13 files changed, 91 insertions(+), 51 deletions(-)
 create mode 100644 Misc/NEWS.d/next/Core and Builtins/2018-10-20-18-05-58.bpo-16806.zr3A9N.rst

----------
nosy: +Anthony Sottile

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

From report at bugs.python.org  Mon Jan  6 05:14:41 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 10:14:41 +0000
Subject: [issue39209] Crash on REPL mode with long text copy and paste
In-Reply-To: <1578148172.19.0.147940927734.issue39209@roundup.psfhosted.org>
Message-ID: <1578305681.01.0.723112467188.issue39209@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Jan  6 05:24:05 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Jan 2020 10:24:05 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578306245.04.0.195879041284.issue39191@roundup.psfhosted.org>


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

This commit seems to generate some warnings in the nested run_until_complete test. The check for running loop is now done at run_until_complete itself before going through the below code in it to create a future and raised a RuntimeError by run_forever as the test used to do. Not sure why CI doesn't have these warnings.

PYTHONWARNINGS=always ./python.exe -m test test_asyncio -m test_run_until_complete_nesting
0:00:00 load avg: 2.16 Run tests sequentially
0:00:00 load avg: 2.16 [1/1] test_asyncio
/Users/kasingar/stuff/python/cpython/Lib/traceback.py:220: RuntimeWarning: coroutine 'EventLoopTestsMixin.test_run_until_complete_nesting.<locals>.coro1' was never awaited
  tb.tb_frame.clear()
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
/Users/kasingar/stuff/python/cpython/Lib/traceback.py:220: RuntimeWarning: coroutine 'EventLoopTestsMixin.test_run_until_complete_nesting.<locals>.coro1' was never awaited
  tb.tb_frame.clear()
RuntimeWarning: Enable tracemalloc to get the object allocation traceback
/Users/kasingar/stuff/python/cpython/Lib/traceback.py:220: RuntimeWarning: coroutine 'EventLoopTestsMixin.test_run_until_complete_nesting.<locals>.coro1' was never awaited
  tb.tb_frame.clear()
RuntimeWarning: Enable tracemalloc to get the object allocation traceback

== Tests result: SUCCESS ==

1 test OK.

Total duration: 164 ms
Tests result: SUCCESS

----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Jan  6 05:28:11 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 10:28:11 +0000
Subject: [issue39209] Crash on REPL mode with long text copy and paste
In-Reply-To: <1578148172.19.0.147940927734.issue39209@roundup.psfhosted.org>
Message-ID: <1578306491.73.0.88607738672.issue39209@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Jan  6 06:00:07 2020
From: report at bugs.python.org (=?utf-8?q?Sindri_Gu=C3=B0mundsson?=)
Date: Mon, 06 Jan 2020 11:00:07 +0000
Subject: [issue39190] _result_handler dies on raised exceptions
 [multiprocessing]
In-Reply-To: <1577968013.94.0.930637470909.issue39190@roundup.psfhosted.org>
Message-ID: <1578308407.69.0.599854005037.issue39190@roundup.psfhosted.org>


Change by Sindri Gu?mundsson <sindrigudmundsson at gmail.com>:


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

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

From report at bugs.python.org  Mon Jan  6 06:47:03 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 06 Jan 2020 11:47:03 +0000
Subject: [issue39209] Crash on REPL mode with long text copy and paste
In-Reply-To: <1578148172.19.0.147940927734.issue39209@roundup.psfhosted.org>
Message-ID: <1578311223.63.0.824065986224.issue39209@roundup.psfhosted.org>


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

@pablogsal

Works correct with PR 17860 :)


Python 3.9.0a2+ (heads/pr/17860:958541d67c, Jan  6 2020, 20:45:49)
[Clang 11.0.0 (clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a = """<?xml version="1.0" encoding="iso-8859-1"?>
... <test>
...     <Users>
...         <fun25>
...             <limits>
...                 <total>0KiB</total>
...                 <kbps>0</kbps>
...                 <rps>1.3</rps>
...                 <connections>0</connections>
...             </limits>
...             <usages>
...                 <total>16738211KiB</total>
...                 <kbps>237.15</kbps>
...                 <rps>1.3</rps>
...                 <connections>0</connections>
...             </usages>
...             <time_to_refresh>never</time_to_refresh>
...             <limit_exceeded_URL>none</limit_exceeded_URL>
...         </fun25>
...     </Users>
... </test>
... """
>>> a
'<?xml version="1.0" encoding="iso-8859-1"?>\n<test>\n    <Users>\n        <fun25>\n            <limits>\n                <total>0KiB</total>\n                <kbps>0</kbps>\n                <rps>1.3</rps>\n                <connections>0</connections>\n            </limits>\n            <usages>\n                <total>16738211KiB</total>\n                <kbps>237.15</kbps>\n                <rps>1.3</rps>\n                <connections>0</connections>\n            </usages>\n            <time_to_refresh>never</time_to_refresh>\n            <limit_exceeded_URL>none</limit_exceeded_URL>\n        </fun25>\n    </Users>\n</test>\n'
>>>

----------

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

From report at bugs.python.org  Mon Jan  6 06:48:24 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 06 Jan 2020 11:48:24 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578311304.08.0.419124387178.issue39191@roundup.psfhosted.org>


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

Ooh, you are right.
The warning is printed only, test runner thinks that the test is ok.
I'll prepare a quick fix.

----------
assignee:  -> asvetlov
status: closed -> open

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

From report at bugs.python.org  Mon Jan  6 06:48:35 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 06 Jan 2020 11:48:35 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578311315.21.0.395917450746.issue39191@roundup.psfhosted.org>


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

Thanks for the report!

----------

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

From report at bugs.python.org  Mon Jan  6 07:03:12 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 06 Jan 2020 12:03:12 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578312192.49.0.531391834003.issue39191@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Jan  6 07:34:13 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jan 2020 12:34:13 +0000
Subject: [issue38907] http.server (command) fails to bind dual-stack on Windows
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1578314053.92.0.871263817782.issue38907@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 5ed9d60bc53e2eb0a88f07d5afe5299acdc0b216 by Jason R. Coombs (Miss Islington (bot)) in branch '3.8':
bpo-38907: In http.server script, restore binding to IPv4 on Windows. (GH-17851) (#17854)
https://github.com/python/cpython/commit/5ed9d60bc53e2eb0a88f07d5afe5299acdc0b216


----------

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

From report at bugs.python.org  Mon Jan  6 07:35:03 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 12:35:03 +0000
Subject: [issue18930] os.spawnXX functions terminates process if second
 argument is empty list
In-Reply-To: <1378378354.78.0.544374922966.issue18930@psf.upfronthosting.co.za>
Message-ID: <1578314103.33.0.852495291316.issue18930@roundup.psfhosted.org>


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

Closing as this also does not happen anymore on master as well.

----------
nosy: +pablogsal
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Jan  6 07:35:21 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jan 2020 12:35:21 +0000
Subject: [issue38907] http.server (command) fails to bind dual-stack on Windows
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1578314121.77.0.578925735569.issue38907@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +17281
pull_request: https://github.com/python/cpython/pull/17864

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

From report at bugs.python.org  Mon Jan  6 07:57:35 2020
From: report at bugs.python.org (Carl Friedrich Bolz-Tereick)
Date: Mon, 06 Jan 2020 12:57:35 +0000
Subject: [issue39220] constant folding affects annotations despite 'from
 __future__ import annotations'
In-Reply-To: <1578230811.94.0.250306045254.issue39220@roundup.psfhosted.org>
Message-ID: <1578315455.56.0.537924842885.issue39220@roundup.psfhosted.org>


Carl Friedrich Bolz-Tereick <cfbolz at gmx.de> added the comment:

I don't have a particularly deep opinion on what should be done, just a bit of weirdness I hit upon while implementing the PEP in PyPy. fwiw, we implement it as an AST transformer that the compiler runs before running the optimizer to make sure that the AST optimizations don't get applied to annotions. The transformer replaces all annotations with a Constant ast node, containing the unparsed string.

----------

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

From report at bugs.python.org  Mon Jan  6 07:59:43 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jan 2020 12:59:43 +0000
Subject: [issue38907] http.server (command) fails to bind dual-stack on Windows
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1578315583.18.0.0312928748699.issue38907@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 7cdc31a14c824000cbe8b487900c9826a33f6940 by Jason R. Coombs in branch 'master':
bpo-38907: Suppress any exception when attempting to set V6ONLY. (GH-17864)
https://github.com/python/cpython/commit/7cdc31a14c824000cbe8b487900c9826a33f6940


----------

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

From report at bugs.python.org  Mon Jan  6 07:59:49 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 12:59:49 +0000
Subject: [issue38907] http.server (command) fails to bind dual-stack on Windows
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1578315589.42.0.511441045896.issue38907@roundup.psfhosted.org>


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


----------
pull_requests: +17282
pull_request: https://github.com/python/cpython/pull/17865

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

From report at bugs.python.org  Mon Jan  6 08:21:27 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 06 Jan 2020 13:21:27 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578316887.94.0.328474731436.issue39200@roundup.psfhosted.org>


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

@pablogsal 
PR 17813 is merged. 
If you don't mind, can we review PR 17814 that will be applied or not?

----------

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

From report at bugs.python.org  Mon Jan  6 08:28:30 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jan 2020 13:28:30 +0000
Subject: [issue38907] http.server (command) fails to bind dual-stack on Windows
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1578317310.94.0.968047290609.issue38907@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 33cb4a62bf6848093b7a05c9794582d204798b1b by Jason R. Coombs (Miss Islington (bot)) in branch '3.8':
bpo-38907: Suppress any exception when attempting to set V6ONLY. (GH-17864) (GH-17865)
https://github.com/python/cpython/commit/33cb4a62bf6848093b7a05c9794582d204798b1b


----------

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

From report at bugs.python.org  Mon Jan  6 08:30:04 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 06 Jan 2020 13:30:04 +0000
Subject: [issue38907] http.server (command) fails to bind dual-stack on Windows
In-Reply-To: <1574615050.93.0.813655289277.issue38907@roundup.psfhosted.org>
Message-ID: <1578317404.61.0.512083101981.issue38907@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In PR 17378, we discussed and I believe the conclusion is that the fix in the other PR(s) is sufficient to address the deficiency.

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

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

From report at bugs.python.org  Mon Jan  6 08:56:35 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 13:56:35 +0000
Subject: [issue39220] constant folding affects annotations despite 'from
 __future__ import annotations'
In-Reply-To: <1578230811.94.0.250306045254.issue39220@roundup.psfhosted.org>
Message-ID: <1578318995.4.0.165292674666.issue39220@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Jan  6 08:57:56 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 13:57:56 +0000
Subject: [issue39220] constant folding affects annotations despite 'from
 __future__ import annotations'
In-Reply-To: <1578230811.94.0.250306045254.issue39220@roundup.psfhosted.org>
Message-ID: <1578319076.86.0.969795067853.issue39220@roundup.psfhosted.org>


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

>> I don't have a particularly deep opinion on what should be done, just a bit of weirdness I hit upon while implementing the PEP in PyPy. fwiw, we implement it as an AST transformer that the compiler runs before running the optimizer to make sure that the AST optimizations don't get applied to annotions. The transformer replaces all annotations with a Constant ast node, containing the unparsed string.


I have given it a try in PR 17866 and it was not as invasive as I imagine, so if ?ukasz agrees, we can go ahead :)

----------

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

From report at bugs.python.org  Mon Jan  6 09:38:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Jan 2020 14:38:49 +0000
Subject: [issue25872] multithreading traceback KeyError when modifying file
In-Reply-To: <1450200064.35.0.872448112145.issue25872@psf.upfronthosting.co.za>
Message-ID: <1578321529.89.0.59877572631.issue25872@roundup.psfhosted.org>


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

Thanks Michael, reopening. I was wrong while trying the reproducer since map is lazy in Python 3 and threads were not executed.

----------
resolution: wont fix -> 
stage: resolved -> 
status: closed -> open
versions: +Python 3.9 -Python 2.7

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

From report at bugs.python.org  Mon Jan  6 09:44:47 2020
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 06 Jan 2020 14:44:47 +0000
Subject: [issue34480] _markupbase.py fails with UnboundLocalError on invalid
 keyword in marked section
In-Reply-To: <1535045437.7.0.56676864532.issue34480@psf.upfronthosting.co.za>
Message-ID: <1578321887.16.0.372956775584.issue34480@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think so.
It might be worth double-checking if BeautifulSoup (and possibly other 3rd party libs) use _markupbase.py and/or ParserBase.error().  If they do, giving them a heads up and/or going through a regular deprecation process might be good, otherwise PR 8562 can be reopened and merged after removing the call to self.error() in ParserBase.parse_marked_section().

----------

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

From report at bugs.python.org  Mon Jan  6 09:56:11 2020
From: report at bugs.python.org (mmckerns)
Date: Mon, 06 Jan 2020 14:56:11 +0000
Subject: [issue39230] fail on datetime import if _datetime.py exists in PATH
Message-ID: <1578322571.14.0.441191353008.issue39230@roundup.psfhosted.org>


New submission from mmckerns <mmckerns at caltech.edu>:

In Lib/datetime.py, there's an import: `from _datetime import *`
which will fail if `_datetime.py` exists in the current directory, or earlier in the path than Lib.  For reference, see:
https://github.com/numpy/numpy/issues/15257

----------
components: Library (Lib)
messages: 359429
nosy: mmckerns
priority: normal
severity: normal
status: open
title: fail on datetime import if _datetime.py exists in PATH
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Jan  6 09:56:41 2020
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 06 Jan 2020 14:56:41 +0000
Subject: [issue39212] Show qualified function name when giving arguments error
In-Reply-To: <1578163945.77.0.403027118696.issue39212@roundup.psfhosted.org>
Message-ID: <1578322601.41.0.383953374735.issue39212@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

> But I *did* get that text. I'm asking how you got the *different* text 
> which you gave in your initial request.

Oh, right. Looking back, turns out Wing IDE did that for me. Didn't notice, sorry.

> So in my opinion, and I recognise that you may disagree, this is only of 
> benefit in a minority of cases. For the majority of cases, it will only 
> be additional noise in the message that adds nothing that wasn't already 
> obvious from the source line.

I understand your perspective.

One correction though regarding adding noise to the error. You gave this example:

    builtins.TypeError: package.some_module.MyClass.__init__ takes 1 positional argument but 2 were given
    
While actually it'll be:

    TypeError: MyClass.__init__ takes 1 positional argument but 2 were given
    
Since __qualname__ only includes the class, not its module. So it's quite a bit shorter.

----------

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

From report at bugs.python.org  Mon Jan  6 10:21:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 15:21:33 +0000
Subject: [issue39230] fail on datetime import if _datetime.py exists in PATH
In-Reply-To: <1578322571.14.0.441191353008.issue39230@roundup.psfhosted.org>
Message-ID: <1578324093.22.0.540295283004.issue39230@roundup.psfhosted.org>


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

This issue is not a bug. You should not use the same module name, than a stdlib module. For example, if you have a "sys.py" file in your Python path (PYTHONPATH), you will get big troubles.

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

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

From report at bugs.python.org  Mon Jan  6 10:59:13 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 15:59:13 +0000
Subject: [issue39209] Crash on REPL mode with long text copy and paste
In-Reply-To: <1578148172.19.0.147940927734.issue39209@roundup.psfhosted.org>
Message-ID: <1578326353.26.0.0918646602188.issue39209@roundup.psfhosted.org>


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


New changeset 5ec91f78d59d9c39b984f284e00cd04b96ddb5db by Pablo Galindo in branch 'master':
bpo-39209: Manage correctly multi-line tokens in interactive mode (GH-17860)
https://github.com/python/cpython/commit/5ec91f78d59d9c39b984f284e00cd04b96ddb5db


----------

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

From report at bugs.python.org  Mon Jan  6 10:59:37 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 15:59:37 +0000
Subject: [issue39209] Crash on REPL mode with long text copy and paste
In-Reply-To: <1578148172.19.0.147940927734.issue39209@roundup.psfhosted.org>
Message-ID: <1578326377.93.0.754979104175.issue39209@roundup.psfhosted.org>


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


----------
pull_requests: +17284
pull_request: https://github.com/python/cpython/pull/17867

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

From report at bugs.python.org  Mon Jan  6 11:20:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 16:20:30 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1578327630.8.0.617729237277.issue35561@roundup.psfhosted.org>


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

On my Fedora 31, epoll_event structure is defined in sys/epoll.h as:

typedef union epoll_data
{
  void *ptr;
  int fd;
  uint32_t u32;
  uint64_t u64;
} epoll_data_t;

struct epoll_event
{
  uint32_t events;	/* Epoll events */
  epoll_data_t data;	/* User data variable */
} __EPOLL_PACKED;


I can reproduce the issue using this Python script:

import select
p = select.epoll()
p.register(1, select.EPOLLIN)
p.poll(0)

The Linux syscall is defined as:

asmlinkage long sys_epoll_ctl(int epfd, int op, int fd,
				struct epoll_event __user *event);

It's implemented in fs/eventpoll.c:

https://github.com/torvalds/linux/blob/c79f46a282390e0f5b306007bf7b11a46d529538/fs/eventpoll.c#L2077-L2083

Valgrind complains that ev.data is only partially initialized: it's a 64-bit structure, but we only set ev.data.fd. I guess that the glibc implements epoll_ctl() as a raw system call: Valgrind is unable to know if it's ok to only partially initialize the epoll_data union.


Benjamin: "I suspect Valgrind is being too conservative. union epoll_data is 64 bits wide but the file descriptor only occupies the first 32 bits. The last 32 bits don't need to be initialized by the application."

Right. But Valgrind is not smart enough.

I see 2 options:

* Initialize ev.data to 0
* Use Misc/valgrind-python.supp to ignore this *false alarm*

----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Jan  6 11:22:27 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 16:22:27 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1578327747.62.0.949068349689.issue39041@roundup.psfhosted.org>


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


----------
pull_requests: +17285
pull_request: https://github.com/python/cpython/pull/17868

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

From report at bugs.python.org  Mon Jan  6 11:22:35 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 16:22:35 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1578327755.78.0.651725568861.issue39041@roundup.psfhosted.org>


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


----------
pull_requests: +17286
pull_request: https://github.com/python/cpython/pull/17869

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

From report at bugs.python.org  Mon Jan  6 11:23:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 16:23:58 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1578327838.91.0.109258637344.issue35561@roundup.psfhosted.org>


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

> Initialize ev.data to 0

I dislike this option, since the code is legit: Valgrind produces a false alarm.

> Use Misc/valgrind-python.supp to ignore this *false alarm*

I prefer this option.

----------

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

From report at bugs.python.org  Mon Jan  6 11:26:17 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 16:26:17 +0000
Subject: [issue39209] Crash on REPL mode with long text copy and paste
In-Reply-To: <1578148172.19.0.147940927734.issue39209@roundup.psfhosted.org>
Message-ID: <1578327977.63.0.786386689261.issue39209@roundup.psfhosted.org>


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


New changeset b2e281aaa2e4a1f24671d293dfd06b23bb052e47 by Miss Islington (bot) in branch '3.8':
bpo-39209: Manage correctly multi-line tokens in interactive mode (GH-17860)
https://github.com/python/cpython/commit/b2e281aaa2e4a1f24671d293dfd06b23bb052e47


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

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

From report at bugs.python.org  Mon Jan  6 11:27:13 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 16:27:13 +0000
Subject: [issue39209] Crash on REPL mode with long text copy and paste
In-Reply-To: <1578148172.19.0.147940927734.issue39209@roundup.psfhosted.org>
Message-ID: <1578328033.77.0.9474937229.issue39209@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Jan  6 11:47:03 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jan 2020 16:47:03 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1578329223.01.0.125741994266.issue39041@roundup.psfhosted.org>


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


New changeset 0048833e1308d39dc9c6489da7872ade0f14486f by Steve Dower (Miss Islington (bot)) in branch '3.8':
bpo-39041: Add GitHub Actions support (GH-17594)
https://github.com/python/cpython/commit/0048833e1308d39dc9c6489da7872ade0f14486f


----------

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

From report at bugs.python.org  Mon Jan  6 11:47:13 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jan 2020 16:47:13 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1578329233.94.0.392917985053.issue39041@roundup.psfhosted.org>


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


New changeset acf5e5f3f42a3d2985499df82331705edbe717be by Steve Dower (Miss Islington (bot)) in branch '3.7':
bpo-39041: Add GitHub Actions support (GH-17594)
https://github.com/python/cpython/commit/acf5e5f3f42a3d2985499df82331705edbe717be


----------

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

From report at bugs.python.org  Mon Jan  6 11:57:38 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jan 2020 16:57:38 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578329858.07.0.583128158511.issue29778@roundup.psfhosted.org>


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


New changeset 7b79dc9200a19ecbac667111dffd58e314be02a8 by Steve Dower (Anthony Wee) in branch 'master':
bpo-29778: Fix incorrect NULL check in _PyPathConfig_InitDLLPath() (GH-17818)
https://github.com/python/cpython/commit/7b79dc9200a19ecbac667111dffd58e314be02a8


----------

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

From report at bugs.python.org  Mon Jan  6 11:58:20 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jan 2020 16:58:20 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578329900.43.0.334080337149.issue29778@roundup.psfhosted.org>


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

Thanks, Anthony! And congratulations on becoming a CPython contributor!

----------

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

From report at bugs.python.org  Mon Jan  6 11:58:32 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jan 2020 16:58:32 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578329912.48.0.30115700099.issue29778@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Jan  6 11:59:02 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 16:59:02 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578329942.59.0.523273584487.issue29778@roundup.psfhosted.org>


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


----------
pull_requests: +17287
pull_request: https://github.com/python/cpython/pull/17871

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

From report at bugs.python.org  Mon Jan  6 12:17:43 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 17:17:43 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578331063.3.0.330422140224.issue29778@roundup.psfhosted.org>


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


New changeset a9a43c221bf3896ed1d1c2eee2531b7121cf78e4 by Miss Islington (bot) in branch '3.8':
bpo-29778: Fix incorrect NULL check in _PyPathConfig_InitDLLPath() (GH-17818)
https://github.com/python/cpython/commit/a9a43c221bf3896ed1d1c2eee2531b7121cf78e4


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

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

From report at bugs.python.org  Mon Jan  6 12:22:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 17:22:26 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578331346.85.0.0468660359111.issue29778@roundup.psfhosted.org>


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

Oops, I'm guilty of pushing this change! Sorry & thanks for the fix.

    if (_Py_dll_path == NULL) {
        /* Already set: nothing to do */
        return _PyStatus_OK();
    }

----------

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

From report at bugs.python.org  Mon Jan  6 13:03:29 2020
From: report at bugs.python.org (mmckerns)
Date: Mon, 06 Jan 2020 18:03:29 +0000
Subject: [issue39230] fail on datetime import if _datetime.py exists in PATH
In-Reply-To: <1578322571.14.0.441191353008.issue39230@roundup.psfhosted.org>
Message-ID: <1578333809.35.0.0366725229392.issue39230@roundup.psfhosted.org>


mmckerns <mmckerns at caltech.edu> added the comment:

Sure, that's obvious for `datetime` and `sys`.  Less obvious for unexpected conflicts with stdlib modules that begin with an underscore...

----------

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

From report at bugs.python.org  Mon Jan  6 13:11:51 2020
From: report at bugs.python.org (Robert)
Date: Mon, 06 Jan 2020 18:11:51 +0000
Subject: [issue39231] Mistaken notion in tutorial
Message-ID: <1578334311.83.0.989380005846.issue39231@roundup.psfhosted.org>


New submission from Robert <freshbob1337 at gmail.com>:

https://docs.python.org/3/tutorial/controlflow.html
4.7.8. Function Annotations
[...] "The following example has a positional argument, a keyword argument, and the return value annotated:"

It is not a "positional argument" but an "optional argument".

----------
assignee: docs at python
components: Documentation
messages: 359443
nosy: docs at python, r0b
priority: normal
severity: normal
status: open
title: Mistaken notion in tutorial
type: enhancement

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

From report at bugs.python.org  Mon Jan  6 13:16:41 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Jan 2020 18:16:41 +0000
Subject: [issue39226] venv does not include pythonXX.lib
In-Reply-To: <1578264613.69.0.856144088862.issue39226@roundup.psfhosted.org>
Message-ID: <1578334601.27.0.675359950826.issue39226@roundup.psfhosted.org>


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

When have you seen this work previously? On my Windows 10 machine there is no Scripts\libs directory for Python 3.7, let alone a python37.lib file in any directory that I can find.

----------
nosy: +brett.cannon, vinay.sajip

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

From report at bugs.python.org  Mon Jan  6 13:18:32 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Jan 2020 18:18:32 +0000
Subject: [issue39225] Python should warn when a global/local has the same name
 as a builtin
In-Reply-To: <1578262689.16.0.500995659902.issue39225@roundup.psfhosted.org>
Message-ID: <1578334712.77.0.477690291363.issue39225@roundup.psfhosted.org>


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

I agree with Eric that this is the realm of linters as there are legitimate reasons sometimes to mask and redefine built-ins.

Thanks for the idea, Reuven, but I'm closing the issue.

----------
nosy: +brett.cannon
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Jan  6 13:20:23 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 06 Jan 2020 18:20:23 +0000
Subject: [issue39221] Cross compiled python installed wrong version of
 lib2to3/Grammar pickle
In-Reply-To: <1578231683.23.0.24612692977.issue39221@roundup.psfhosted.org>
Message-ID: <1578334823.53.0.427169887887.issue39221@roundup.psfhosted.org>


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


----------
versions:  -Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jan  6 13:21:58 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Jan 2020 18:21:58 +0000
Subject: [issue39204] Automate adding Type Annotations to Documentation
In-Reply-To: <1578078745.51.0.848404810387.issue39204@roundup.psfhosted.org>
Message-ID: <1578334918.73.0.964809099503.issue39204@roundup.psfhosted.org>


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

I think a bigger thing is to simply get type annotations to be used in the stdlib first, then we can worry about documenting them as part of the API. :)

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Mon Jan  6 13:25:00 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Jan 2020 18:25:00 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578335100.63.0.593046862032.issue38623@roundup.psfhosted.org>


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

I agree with Inada-san that pointing out how to get the file path on a module is a better solution then explaining directory layouts which are borderline implementation details.

----------

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

From report at bugs.python.org  Mon Jan  6 13:29:20 2020
From: report at bugs.python.org (Michael Hall)
Date: Mon, 06 Jan 2020 18:29:20 +0000
Subject: [issue39232] asyncio crashes when tearing down the proactor event loop
Message-ID: <1578335360.75.0.333919607495.issue39232@roundup.psfhosted.org>


New submission from Michael Hall <michael at michaelhall.tech>:

When using asyncio.run for an asynchronous application utilizing ssl, on windows using the proactor event loop the application crashes when the loop is closed, completely skipping a finally block in the process.

This appears to be due to a __del__ method on transports used.

Manual handling of the event loop close while including a brief sleep appears to work as intended.

Both versions work fine with the selector event loop on linux.

This appears to be a somewhat known issue already, as it's been reported to aiohttp, however both the traceback, and the differing behavior seem to indicate this is an issue with the proactor event loop.

(On linux this still emits a resource warning without the sleep)

While I don't mind handling the loop cleanup, it seems like this case should also emit a resource warning rather than crashing.

If it's decided in which way this should be handled, I'm willing to contribute to or help test whatever direction the resolution for this should go. 

Traceback included below, toy version of the problem attached as code.

Exception ignored in: <function _ProactorBasePipeTransport.__del__ at 0x0000026463039820>
Traceback (most recent call last):
  File "C:\Users\Michael\AppData\Local\Programs\Python\Python38\lib\asyncio\proactor_events.py", line 116, in __del__
    self.close()
  File "C:\Users\Michael\AppData\Local\Programs\Python\Python38\lib\asyncio\proactor_events.py", line 108, in close
    self._loop.call_soon(self._call_connection_lost, None)
  File "C:\Users\Michael\AppData\Local\Programs\Python\Python38\lib\asyncio\base_events.py", line 715, in call_soon
    self._check_closed()
  File "C:\Users\Michael\AppData\Local\Programs\Python\Python38\lib\asyncio\base_events.py", line 508, in _check_closed       
    raise RuntimeError('Event loop is closed')
RuntimeError: Event loop is closed

----------
components: asyncio
files: example.py
messages: 359448
nosy: asvetlov, mikeshardmind, yselivanov
priority: normal
severity: normal
status: open
title: asyncio crashes when tearing down the proactor event loop
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file48829/example.py

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

From report at bugs.python.org  Mon Jan  6 13:30:12 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 06 Jan 2020 18:30:12 +0000
Subject: [issue39204] Automate adding Type Annotations to Documentation
In-Reply-To: <1578078745.51.0.848404810387.issue39204@roundup.psfhosted.org>
Message-ID: <1578335412.25.0.587223955215.issue39204@roundup.psfhosted.org>


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

Actually I agree with the OP that we could get some mileage out of joining typeshed with the docs, regardless of whether there are annotations in the stdlib.

----------

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

From report at bugs.python.org  Mon Jan  6 13:52:06 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 06 Jan 2020 18:52:06 +0000
Subject: [issue30717] Add unicode grapheme cluster break algorithm
In-Reply-To: <1497986122.28.0.540580196076.issue30717@psf.upfronthosting.co.za>
Message-ID: <1578336726.11.0.94942387971.issue30717@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> Oh, also, if y'all are fine with binding to Rust (through a C ABI) I'd love to help y'all use unicode-segmentation, which is much less work that pulling in ICU. Otherwise if y'all have implementation questions I can answer them. This spec is kinda tricky to implement efficiently, but it's not super hard.

Is the idea here that we'd take on a new dependency on the compiled `unicode-segmentation` binary, rather than adding Rust into our build system? Does `unicode-segmentation` support all platforms that CPython supports? I was under the impression that Rust requires llvm and llvm doesn't necessarily have the same support matrix as CPython (I'd love to be corrected if I'm wrong on this).

(Note: I don't actually know what the process is for taking on new dependencies like this, just trying to point at one possible stumbling block.)

----------

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

From report at bugs.python.org  Mon Jan  6 13:54:50 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 06 Jan 2020 18:54:50 +0000
Subject: [issue39233] glossary entry for parameter out-of-date for
 positional-only parameters
Message-ID: <1578336890.4.0.142758348692.issue39233@roundup.psfhosted.org>


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

The glossary entry for parameter[1] says:

> Python has no syntax for defining positional-only parameters.

Since PEP 570 landed in Python 3.8, that's no longer true.


[1] https://docs.python.org/3/glossary.html#term-parameter

----------
assignee: docs at python
components: Documentation
messages: 359451
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: glossary entry for parameter out-of-date for positional-only parameters
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jan  6 14:07:17 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 06 Jan 2020 19:07:17 +0000
Subject: [issue39233] glossary entry for parameter out-of-date for
 positional-only parameters
In-Reply-To: <1578336890.4.0.142758348692.issue39233@roundup.psfhosted.org>
Message-ID: <1578337637.26.0.356555021998.issue39233@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Jan  6 14:10:39 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Mon, 06 Jan 2020 19:10:39 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
Message-ID: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>


New submission from YoSTEALTH <ritesh at stealthcentral.com>:

# enum in C
# ---------
enum {
    a,
    b,
    c
}
# a = 0
# b = 1
# b = 2

# enum in Python
# --------------
class Count(enum.IntEnum):
    a = enum.auto()
    b = enum.auto()
    c = enum.auto()
# a = 1
# b = 2
# b = 3


I am not sure why the `enum.auto()` starts with 1 in Python but this has just wasted a week worth of my time.

----------
assignee: docs at python
components: Documentation
messages: 359452
nosy: YoSTEALTH, docs at python
priority: normal
severity: normal
status: open
title: `enum.auto()` incrementation value not specified.
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jan  6 14:13:06 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Mon, 06 Jan 2020 19:13:06 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
In-Reply-To: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>
Message-ID: <1578337986.14.0.191541635385.issue39234@roundup.psfhosted.org>


Change by YoSTEALTH <ritesh at stealthcentral.com>:


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

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

From report at bugs.python.org  Mon Jan  6 14:20:48 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jan 2020 19:20:48 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1578338448.83.0.546376034812.issue39041@roundup.psfhosted.org>


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


----------
pull_requests: +17289
pull_request: https://github.com/python/cpython/pull/17873

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

From report at bugs.python.org  Mon Jan  6 14:24:07 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 06 Jan 2020 19:24:07 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1578338647.01.0.558859648481.issue39158@roundup.psfhosted.org>


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

> The function literal_eval is not safe anymore as the 
> constructor can be intercepted

"Safe" means safe from user input to literal_eval().

If a person can already write arbitrary code that redefines a builtin, then they can already do anything they want.

----------

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

From report at bugs.python.org  Mon Jan  6 14:27:27 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 06 Jan 2020 19:27:27 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
Message-ID: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>


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

A normal generator expression like (i for i in a) produces the following AST:

Module(
    body=[
        Expr(
            value=GeneratorExp(
                elt=Name(
                    id="i", ctx=Load(), lineno=1, col_offset=1, end_lineno=1, end_col_offset=2
                ),
                generators=[
                    comprehension(
                        target=Name(
                            id="i",
                            ctx=Store(),
                            lineno=1,
                            col_offset=7,
                            end_lineno=1,
                            end_col_offset=8,
                        ),
                        iter=Name(
                            id="a",
                            ctx=Load(),
                            lineno=1,
                            col_offset=12,
                            end_lineno=1,
                            end_col_offset=13,
                        ),
                        ifs=[],
                        is_async=0,
                    )
                ],
                lineno=1,
                *col_offset=0,*
                end_lineno=1,
                *end_col_offset=14,*
            ),
            lineno=1,
            col_offset=0,
            end_lineno=1,
            end_col_offset=14,
        )
    ],
    type_ignores=[],
)

But when calling a function with a generator expression as an argument, something is off:

Module(
    body=[
        Expr(
            value=Call(
                func=Name(
                    id="f", ctx=Load(), lineno=1, col_offset=0, end_lineno=1, end_col_offset=1
                ),
                args=[
                    GeneratorExp(
                        elt=Name(
                            id="i",
                            ctx=Load(),
                            lineno=1,
                            col_offset=2,
                            end_lineno=1,
                            end_col_offset=3,
                        ),
                        generators=[
                            comprehension(
                                target=Name(
                                    id="i",
                                    ctx=Store(),
                                    lineno=1,
                                    col_offset=8,
                                    end_lineno=1,
                                    end_col_offset=9,
                                ),
                                iter=Name(
                                    id="a",
                                    ctx=Load(),
                                    lineno=1,
                                    col_offset=13,
                                    end_lineno=1,
                                    end_col_offset=14,
                                ),
                                ifs=[],
                                is_async=0,
                            )
                        ],
                        lineno=1,
                        *col_offset=1,*
                        end_lineno=1,
                        *end_col_offset=2,*
                    )
                ],
                keywords=[],
                lineno=1,
                col_offset=0,
                end_lineno=1,
                end_col_offset=15,
            ),
            lineno=1,
            col_offset=0,
            end_lineno=1,
            end_col_offset=15,
        )
    ],
    type_ignores=[],
)


I'm not sure if this is intentional or not, because there is a call to copy_location in Python/ast.c:3149. If this call to copy_location is removed, the inconsistency goes away.

----------
components: Interpreter Core
messages: 359454
nosy: lys.nikolaou
priority: normal
severity: normal
status: open
title: Generator expression has wrong line/col info when inside a Call object
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jan  6 14:31:40 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 19:31:40 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
In-Reply-To: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>
Message-ID: <1578339100.07.0.918271283397.issue39235@roundup.psfhosted.org>


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

I think that was introduced in  https://bugs.python.org/issue31241

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39235>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:37:10 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 06 Jan 2020 19:37:10 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
In-Reply-To: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>
Message-ID: <1578339430.91.0.310560971381.issue39235@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Do you think it is okay to just remove the call to copy_location?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39235>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:38:11 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 19:38:11 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1578339491.55.0.703530249682.issue39158@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> "Safe" means safe from user input to literal_eval().

Yup, apologies. I had something in mind and I realized after writing my initial comment. That is why I said afterwards:

> and the security concern is non-existent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39158>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:43:35 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 19:43:35 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
In-Reply-To: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>
Message-ID: <1578339815.47.0.848559582394.issue39235@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>Do you think it is okay to just remove the call to copy_location?

I think that because in that case the parenthesis is collapsed with function call parenthesis, the position of the AST node for the generator expression should point to the left parenthesis.

But I would suggest asking Serhiy (I added him to the noisy list) as he was the author of the PR.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39235>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:45:05 2020
From: report at bugs.python.org (Batuhan)
Date: Mon, 06 Jan 2020 19:45:05 +0000
Subject: [issue23147] Possible error in _header_value_parser.py
In-Reply-To: <1420194679.08.0.467668822135.issue23147@psf.upfronthosting.co.za>
Message-ID: <1578339905.61.0.708844070292.issue23147@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

This issue looks resolved.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23147>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:45:05 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Jan 2020 19:45:05 +0000
Subject: [issue39236] Adding a .gitignore file to virtual environments
Message-ID: <1578339905.74.0.21964655851.issue39236@roundup.psfhosted.org>


New submission from Brett Cannon <brett at python.org>:

In a discussion on Twitter, the idea of having venv lay down a .gitignore file in a newly created virtual environment that consisted of nothing but `*` came up (https://twitter.com/codewithanthony/status/1213680829530099713). The purpose would be to help prevent people from inadvertently committing their venv to git. It seems pytest does something similar for .pytest_cache (got one complaint but have chosen to keep it otherwise).

To me this seems like a good enhancement. Since this would mostly benefit beginners then it should probably be an opt-out if we do it at all. Maybe make --no-ignore-file to opt out?

FYI Mercurial does not support subdirectory hgignore files like git does, so this may be git-specific (for now): https://www.selenic.com/mercurial/hgignore.5.html.

----------
components: Library (Lib)
messages: 359459
nosy: brett.cannon, vinay.sajip, xtreak
priority: low
severity: normal
status: open
title: Adding a .gitignore file to virtual environments
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39236>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:45:32 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Jan 2020 19:45:32 +0000
Subject: [issue39236] [venv] Adding a .gitignore file to virtual environments
In-Reply-To: <1578339905.74.0.21964655851.issue39236@roundup.psfhosted.org>
Message-ID: <1578339932.72.0.344572683298.issue39236@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
title: Adding a .gitignore file to virtual environments -> [venv] Adding a .gitignore file to virtual environments

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39236>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:47:29 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Jan 2020 19:47:29 +0000
Subject: [issue38901] [venv] Add a CLI flag to venv to use the pwd basename as
 the prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1578340049.04.0.967438762362.issue38901@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
title: Add a CLI flag to venv to use the pwd basename as the prompt -> [venv] Add a CLI flag to venv to use the pwd basename as the prompt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:47:36 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Jan 2020 19:47:36 +0000
Subject: [issue38972] [venv] Link to instructions to change PowerShell
 execution policy for venv activation
In-Reply-To: <1575483846.28.0.24893284684.issue38972@roundup.psfhosted.org>
Message-ID: <1578340056.74.0.351813706795.issue38972@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
title: Link to instructions to change PowerShell execution policy for venv activation -> [venv] Link to instructions to change PowerShell execution policy for venv activation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38972>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:48:04 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 06 Jan 2020 19:48:04 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
In-Reply-To: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>
Message-ID: <1578340084.83.0.734986560314.issue39234@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

`auto()` starts with 1 because Enum numbering starts at 1 (which is in the docs, albeit buried in the Functional API section).

Thank you for your effort to save somebody else from that frustration, though, I appreciate it.

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39234>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:49:23 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 06 Jan 2020 19:49:23 +0000
Subject: [issue38901] [venv] Add a CLI flag to venv to use the pwd basename as
 the prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1578340163.39.0.051967227687.issue38901@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Any more feedback from anyone on the idea of using the basename of a directory if specified for `--prompt`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:53:09 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 06 Jan 2020 19:53:09 +0000
Subject: [issue39233] glossary entry for parameter out-of-date for
 positional-only parameters
In-Reply-To: <1578336890.4.0.142758348692.issue39233@roundup.psfhosted.org>
Message-ID: <1578340389.57.0.562089289681.issue39233@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +17290
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17874

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39233>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:53:40 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 06 Jan 2020 19:53:40 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
In-Reply-To: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>
Message-ID: <1578340420.19.0.0737297101981.issue39234@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 2e9012a3e1e316c54e27f51ba5849ba06eab7da2 by Ethan Furman (YoSTEALTH) in branch 'master':
bpo-39234: Doc: `enum.auto()` incrementation value not specified. (GH-17872)
https://github.com/python/cpython/commit/2e9012a3e1e316c54e27f51ba5849ba06eab7da2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39234>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:53:52 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 19:53:52 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
In-Reply-To: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>
Message-ID: <1578340432.71.0.60948327186.issue39234@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17291
pull_request: https://github.com/python/cpython/pull/17875

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39234>
_______________________________________

From report at bugs.python.org  Mon Jan  6 14:53:58 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 19:53:58 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
In-Reply-To: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>
Message-ID: <1578340438.92.0.558996691035.issue39234@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17292
pull_request: https://github.com/python/cpython/pull/17876

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39234>
_______________________________________

From report at bugs.python.org  Mon Jan  6 15:04:13 2020
From: report at bugs.python.org (Batuhan)
Date: Mon, 06 Jan 2020 20:04:13 +0000
Subject: [issue22606] Inconsistency between Python 2 and PyPy regarding future
 imports
In-Reply-To: <1412974125.28.0.470692866106.issue22606@psf.upfronthosting.co.za>
Message-ID: <1578341053.74.0.212106806415.issue22606@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I guess this issue expired (due to python2).

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22606>
_______________________________________

From report at bugs.python.org  Mon Jan  6 15:22:49 2020
From: report at bugs.python.org (Alex Henrie)
Date: Mon, 06 Jan 2020 20:22:49 +0000
Subject: [issue39237] Redundant call to round in delta_new
Message-ID: <1578342169.21.0.342179864502.issue39237@roundup.psfhosted.org>


New submission from Alex Henrie <alexhenrie24 at gmail.com>:

The delta_new function in _datetimemodule.c currently contains the following code:

    /* Round to nearest whole # of us, and add into x. */
    double whole_us = round(leftover_us);
    int x_is_odd;
    PyObject *temp;

    whole_us = round(leftover_us);

The second call to the round function produces the same result as the first call and can therefore be safely eliminated.

----------
components: Library (Lib)
messages: 359465
nosy: alex.henrie
priority: normal
severity: normal
status: open
title: Redundant call to round in delta_new
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39237>
_______________________________________

From report at bugs.python.org  Mon Jan  6 15:23:21 2020
From: report at bugs.python.org (Batuhan)
Date: Mon, 06 Jan 2020 20:23:21 +0000
Subject: [issue29154] 5 failures in test_doctest: ModuleNotFoundError: No
 module named 'IPython'
In-Reply-To: <1483544927.48.0.740005145144.issue29154@psf.upfronthosting.co.za>
Message-ID: <1578342201.76.0.845198271591.issue29154@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@Gerrit.Holl do you able to reproduce this with a clean python installation, as @eric.snow suggested there is a chance that some kind of pth hack that tried to inject ipython etc.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29154>
_______________________________________

From report at bugs.python.org  Mon Jan  6 15:25:22 2020
From: report at bugs.python.org (Alex Henrie)
Date: Mon, 06 Jan 2020 20:25:22 +0000
Subject: [issue39237] Redundant call to round in delta_new
In-Reply-To: <1578342169.21.0.342179864502.issue39237@roundup.psfhosted.org>
Message-ID: <1578342322.29.0.935915300213.issue39237@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
keywords: +patch
pull_requests: +17293
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17877

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39237>
_______________________________________

From report at bugs.python.org  Mon Jan  6 15:29:49 2020
From: report at bugs.python.org (Srinivas Nyayapati)
Date: Mon, 06 Jan 2020 20:29:49 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1578342589.06.0.190953338079.issue25172@roundup.psfhosted.org>


Srinivas Nyayapati <shireenrao at gmail.com> added the comment:

@steve.dower - Does this fix need more work for android? @xdegaye says he does not need this for android anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Mon Jan  6 15:39:54 2020
From: report at bugs.python.org (YoSTEALTH)
Date: Mon, 06 Jan 2020 20:39:54 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
In-Reply-To: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>
Message-ID: <1578343194.74.0.0285479261081.issue39234@roundup.psfhosted.org>


Change by YoSTEALTH <ritesh at stealthcentral.com>:


----------
pull_requests: +17294
pull_request: https://github.com/python/cpython/pull/17878

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39234>
_______________________________________

From report at bugs.python.org  Mon Jan  6 16:23:17 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 21:23:17 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1578345797.25.0.306142606008.issue39041@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b1ce22d086660d2505010694c8813cc67adf8f9e by Miss Islington (bot) (Steve Dower) in branch 'master':
bpo-39041: Fix coverage upload command for GitHub Actions (GH-17873)
https://github.com/python/cpython/commit/b1ce22d086660d2505010694c8813cc67adf8f9e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Mon Jan  6 16:23:35 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 21:23:35 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1578345815.44.0.841148901098.issue39041@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17295
pull_request: https://github.com/python/cpython/pull/17879

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Mon Jan  6 16:23:42 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 21:23:42 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1578345822.44.0.394469342508.issue39041@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17296
pull_request: https://github.com/python/cpython/pull/17880

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Mon Jan  6 16:27:55 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jan 2020 21:27:55 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1578346075.26.0.321016126572.issue25172@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I started creating an example of improving the skip cases, and ended up just making a PR. It should:

* expect a helpful error on Windows
* work fine on other platforms with crypt
* skip all tests on other platforms without crypt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Mon Jan  6 16:28:11 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 06 Jan 2020 21:28:11 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1578346091.03.0.941917442374.issue25172@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +17297
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17881

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Mon Jan  6 16:41:36 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 21:41:36 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1578346896.41.0.723811146467.issue39041@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fb59f5ffe80a1f2dcf7c6cbd2406e15bea49da21 by Miss Islington (bot) in branch '3.8':
bpo-39041: Fix coverage upload command for GitHub Actions (GH-17873)
https://github.com/python/cpython/commit/fb59f5ffe80a1f2dcf7c6cbd2406e15bea49da21


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Mon Jan  6 16:42:41 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 21:42:41 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1578346961.33.0.785569011349.issue39041@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 676b16c14040ddb9a2ef3408e66a77c1dfb8e841 by Miss Islington (bot) in branch '3.7':
bpo-39041: Fix coverage upload command for GitHub Actions (GH-17873)
https://github.com/python/cpython/commit/676b16c14040ddb9a2ef3408e66a77c1dfb8e841


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Mon Jan  6 17:04:46 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 06 Jan 2020 22:04:46 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
In-Reply-To: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>
Message-ID: <1578348286.92.0.618395421645.issue39234@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 24bcefcb74231476b055bb6f0726642abeb10f04 by Miss Islington (bot) (YoSTEALTH) in branch 'master':
bpo-39234: `enum.auto()` default initial value as 1 (GH-17878)
https://github.com/python/cpython/commit/24bcefcb74231476b055bb6f0726642abeb10f04


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39234>
_______________________________________

From report at bugs.python.org  Mon Jan  6 17:16:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 22:16:59 +0000
Subject: [issue39238] test_asyncio:
 test_cancel_make_subprocess_transport_exec() hangs randomly on PPC64LE Fedora
 3.x
Message-ID: <1578349019.82.0.0702143761935.issue39238@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

PPC64LE Fedora 3.x buildbot:
https://buildbot.python.org/all/#builders/11/builds/134

0:35:30 load avg: 0.00 [420/420/1] test_asyncio crashed (Exit code 1)
Timeout (0:15:00)!
Thread 0x00003fff82de5330 (most recent call first):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/selectors.py", line 468 in select
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/asyncio/base_events.py", line 1852 in _run_once
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/asyncio/base_events.py", line 596 in run_forever
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/asyncio/base_events.py", line 629 in run_until_complete
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/test/test_asyncio/test_subprocess.py", line 441 in test_cancel_make_subprocess_transport_exec
(...)
0:35:30 load avg: 0.00 Re-running test_asyncio in verbose mode
(...)
test_shell_loop_deprecated (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_start_new_session (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_stdin_broken_pipe (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_stdin_not_inheritable (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_stdin_stdout (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
test_terminate (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
Timeout (0:15:00)!
Thread 0x00003fffb25e5330 (most recent call first):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/selectors.py", line 468 in select
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/asyncio/base_events.py", line 1852 in _run_once
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/asyncio/base_events.py", line 596 in run_forever
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/asyncio/base_events.py", line 629 in run_until_complete
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/test/test_asyncio/test_subprocess.py", line 441 in test_cancel_make_subprocess_transport_exec
  ....

----------
components: Tests, asyncio
messages: 359473
nosy: asvetlov, pablogsal, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio: test_cancel_make_subprocess_transport_exec() hangs randomly on PPC64LE Fedora 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39238>
_______________________________________

From report at bugs.python.org  Mon Jan  6 17:20:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 22:20:27 +0000
Subject: [issue37387] test_compileall fails randomly on Windows when tests are
 run in parallel
In-Reply-To: <1561383626.08.0.320504464802.issue37387@roundup.psfhosted.org>
Message-ID: <1578349227.25.0.487142953044.issue37387@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

x86 Windows7 3.8:
https://buildbot.python.org/all/#/builders/223/builds/59

FAIL: test_no_args_respects_force_flag (test.test_compileall.CommmandLineTestsNoSourceEpoch)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.8.bolen-windows7\build\lib\test\test_py_compile.py", line 20, in wrapper
    return fxn(*args, **kwargs)
  File "D:\cygwin\home\db3l\buildarea\3.8.bolen-windows7\build\lib\test\test_py_compile.py", line 20, in wrapper
    return fxn(*args, **kwargs)
  File "D:\cygwin\home\db3l\buildarea\3.8.bolen-windows7\build\lib\test\test_compileall.py", line 322, in test_no_args_respects_force_flag
    self.assertRunOK('-f', PYTHONPATH=self.directory)
  File "D:\cygwin\home\db3l\buildarea\3.8.bolen-windows7\build\lib\test\test_compileall.py", line 271, in assertRunOK
    rc, out, err = script_helper.assert_python_ok(
  File "D:\cygwin\home\db3l\buildarea\3.8.bolen-windows7\build\lib\test\support\script_helper.py", line 157, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "D:\cygwin\home\db3l\buildarea\3.8.bolen-windows7\build\lib\test\support\script_helper.py", line 143, in _assert_python
    res.fail(cmd_line)
  File "D:\cygwin\home\db3l\buildarea\3.8.bolen-windows7\build\lib\test\support\script_helper.py", line 70, in fail
    raise AssertionError("Process return code is %d\n"
AssertionError: Process return code is 1
command line: ['D:\\cygwin\\home\\db3l\\buildarea\\3.8.bolen-windows7\\build\\PCbuild\\win32\\python_d.exe', '-X', 'faulthandler', '-S', '-m', 'compileall', '-f']

stdout:
---
(...)

Compiling 'D:\\cygwin\\home\\db3l\\buildarea\\3.8.bolen-windows7\\build\\lib\\socketserver.py'...

Compiling 'D:\\cygwin\\home\\db3l\\buildarea\\3.8.bolen-windows7\\build\\lib\\sre_compile.py'...

*** PermissionError: [WinError 5] Access is denied: 'D:\\cygwin\\home\\db3l\\buildarea\\3.8.bolen-windows7\\build\\lib\\__pycache__\\sre_compile.cpython-38.pyc.12753880' -> 'D:\\cygwin\\home\\db3l\\buildarea\\3.8.bolen-windows7\\build\\lib\\__pycache__\\sre_compile.cpython-38.pyc'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37387>
_______________________________________

From report at bugs.python.org  Mon Jan  6 17:25:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 22:25:17 +0000
Subject: [issue39230] fail on datetime import if _datetime.py exists in PATH
In-Reply-To: <1578322571.14.0.441191353008.issue39230@roundup.psfhosted.org>
Message-ID: <1578349517.58.0.270426225053.issue39230@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Sure, that's obvious for `datetime` and `sys`.  Less obvious for unexpected conflicts with stdlib modules that begin with an underscore...

Yeah, sadly, these modules are less known, but cause the same kind of issues :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39230>
_______________________________________

From report at bugs.python.org  Mon Jan  6 17:51:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 22:51:31 +0000
Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition)
 causes reference leak
In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org>
Message-ID: <1578351091.69.0.689442090161.issue37788@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-39074 as a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37788>
_______________________________________

From report at bugs.python.org  Mon Jan  6 17:51:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 22:51:08 +0000
Subject: [issue39074] Threading memory leak in _shutdown_locks for non-daemon
 threads
In-Reply-To: <1576597894.7.0.119079561961.issue39074@roundup.psfhosted.org>
Message-ID: <1578351068.88.0.894569197655.issue39074@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, I close this issue as a duplicate of bpo-37788.

----------
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> fix for bpo-36402 (threading._shutdown() race condition) causes reference leak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39074>
_______________________________________

From report at bugs.python.org  Mon Jan  6 17:53:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 22:53:50 +0000
Subject: [issue39201] Threading.timer leaks memory in 3.8.0/3.8.1
In-Reply-To: <1578065548.82.0.563193246076.issue39201@roundup.psfhosted.org>
Message-ID: <1578351230.25.0.540773573515.issue39201@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I close this issue as a duplicate of bpo-37788.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> fix for bpo-36402 (threading._shutdown() race condition) causes reference leak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39201>
_______________________________________

From report at bugs.python.org  Mon Jan  6 17:54:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 22:54:04 +0000
Subject: [issue37788] fix for bpo-36402 (threading._shutdown() race condition)
 causes reference leak
In-Reply-To: <1565194972.64.0.065323919799.issue37788@roundup.psfhosted.org>
Message-ID: <1578351244.55.0.517713391378.issue37788@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-39201 as a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37788>
_______________________________________

From report at bugs.python.org  Mon Jan  6 17:58:38 2020
From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_M?=)
Date: Mon, 06 Jan 2020 22:58:38 +0000
Subject: [issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem()
In-Reply-To: <1544525657.6.0.788709270274.issue35459@psf.upfronthosting.co.za>
Message-ID: <1578351518.94.0.748990637905.issue35459@roundup.psfhosted.org>


Rapha?l M <raphael.monat at lip6.fr> added the comment:

Any pointer would also be welcome, and a piece of code showing the bug would help me a lot. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35459>
_______________________________________

From report at bugs.python.org  Mon Jan  6 18:34:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 23:34:48 +0000
Subject: [issue39239] select.epoll.unregister(fd) should not ignore EBADF
Message-ID: <1578353688.24.0.722884378041.issue39239@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The select.epoll.unregister(fd) method currently ignores EBADF error if the file descriptor fd is invalid.

I'm surprised by this undocumented behavior:
https://docs.python.org/dev/library/select.html#select.epoll.unregister

This behavior may lead to bugs if the file descriptor number has been recycled in the meanwhile. I'm not sure that it's a good idea to silently ignore the error.

See bpo-18748 for a similar issue: "io.IOBase destructor silence I/O error on close() by default".

Note: The method also ignores EBADF error if the epoll file descriptor has been closed.

The behavior is as old as the implementation of select.epoll, bpo-1657:

commit 0e9ab5f2f0f907b57c70557e21633ce8c341d1d1
Author: Christian Heimes <christian at cheimes.de>
Date:   Fri Mar 21 23:49:44 2008 +0000

    Applied patch #1657 epoll and kqueue wrappers for the select module
    The patch adds wrappers for the Linux epoll syscalls and the BSD kqueue syscalls. Thanks to Thomas Herve and the Twisted people for their support a
nd help.
    TODO: Finish documentation documentation

Thomas Herve wrote a first implementation in bpo-1675118, but it seems like it was Christian Heimes who wrote the unregister() method.

----------
components: Library (Lib)
messages: 359481
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: select.epoll.unregister(fd) should not ignore EBADF
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39239>
_______________________________________

From report at bugs.python.org  Mon Jan  6 18:39:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 06 Jan 2020 23:39:26 +0000
Subject: [issue39239] select.epoll.unregister(fd) should not ignore EBADF
In-Reply-To: <1578353688.24.0.722884378041.issue39239@roundup.psfhosted.org>
Message-ID: <1578353966.61.0.896486009102.issue39239@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17298
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17882

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39239>
_______________________________________

From report at bugs.python.org  Mon Jan  6 19:36:19 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 07 Jan 2020 00:36:19 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1578357379.77.0.940974814034.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17299
pull_request: https://github.com/python/cpython/pull/17883

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Mon Jan  6 19:41:22 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 07 Jan 2020 00:41:22 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1578357682.45.0.995468654106.issue1635741@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Compare to _Py_ForgetReference(), _Py_INC_REFTOTAL in _Py_NewReference() looks redundant.

REF: https://github.com/python/cpython/blob/master/Include/object.h#L442

master brach baseline in my vm:
```
sys.gettotalrefcount(): 18049
sys.gettotalrefcount(): 22463
```

after PR17883
```
sys.gettotalrefcount(): 17589
sys.gettotalrefcount(): 22000
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Mon Jan  6 20:01:11 2020
From: report at bugs.python.org (Gerardo)
Date: Tue, 07 Jan 2020 01:01:11 +0000
Subject: [issue39240] keyerror in string format
Message-ID: <1578358871.82.0.953798300041.issue39240@roundup.psfhosted.org>


New submission from Gerardo <gerry_c89 at yahoo.it>:

Hi, i think tha this is a problem, i'm not have mutch experiencing in programming with python. I have added in the file the line that create the problem and a line that make fully functional. Thanks for the time.
Gerry

----------
components: Regular Expressions
files: test.py
messages: 359483
nosy: ezio.melotti, gerryc89, mrabarnett
priority: normal
severity: normal
status: open
title: keyerror in string format
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file48830/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39240>
_______________________________________

From report at bugs.python.org  Mon Jan  6 20:16:21 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 07 Jan 2020 01:16:21 +0000
Subject: [issue39240] keyerror in string format
In-Reply-To: <1578358871.82.0.953798300041.issue39240@roundup.psfhosted.org>
Message-ID: <1578359781.84.0.414564373168.issue39240@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

When creating a bug report, please show the actual errors that you get. 

This is not a bug in python. In line 5 you're looking for composer2['third'], so of course you'd need to define it.

----------
components:  -Regular Expressions
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39240>
_______________________________________

From report at bugs.python.org  Mon Jan  6 20:19:28 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Jan 2020 01:19:28 +0000
Subject: [issue39240] keyerror in string format
In-Reply-To: <1578358871.82.0.953798300041.issue39240@roundup.psfhosted.org>
Message-ID: <1578359968.52.0.908759303719.issue39240@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Instead of doing lookups with square brackets, consider using the dict.get() method that returns a default value rather than raising a KeyError for a missing key.

    composer2[input1]  --> composer2.get(input1, 0)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39240>
_______________________________________

From report at bugs.python.org  Mon Jan  6 20:33:00 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 07 Jan 2020 01:33:00 +0000
Subject: [issue39227] OverflowError in len(range(2**63))
In-Reply-To: <1578277112.33.0.0446121238087.issue39227@roundup.psfhosted.org>
Message-ID: <1578360780.92.0.0466835824837.issue39227@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39227>
_______________________________________

From report at bugs.python.org  Mon Jan  6 20:35:08 2020
From: report at bugs.python.org (Xu)
Date: Tue, 07 Jan 2020 01:35:08 +0000
Subject: [issue39241] Popen of python3.6 hangs on os.read(errpipe_read, 50000)
Message-ID: <1578360908.03.0.624419556785.issue39241@roundup.psfhosted.org>


New submission from Xu <liuxu1005 at gmail.com>:

I have a piece code hangs on os.read(errpipe_read, 50000)
So I compared the python3.6 with python2.7 on _execute_child, I saw:

for python2.7 we create the errpipe_read/write with pipe_cloexec()

1213             # For transferring possible exec failure from child to parent
1214             # The first char specifies the exception type: 0 means
1215             # OSError, 1 means some other error.
1216             errpipe_read, errpipe_write = self.pipe_cloexec()


while for python3.6 we create the errpipe_read/write with pipe()

1251             # For transferring possible exec failure from child to parent.
1252             # Data format: "exception name:hex errno:description"
1253             # Pickle is not used; it is complex and involves memory allocation.
1254             errpipe_read, errpipe_write = os.pipe()

Does that mean python3.6 doesn't set the the flag FD_CLOEXEC on the pipe ?

----------
components: Library (Lib)
messages: 359486
nosy: liuxu1005
priority: normal
severity: normal
status: open
title: Popen of python3.6 hangs on os.read(errpipe_read, 50000)
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39241>
_______________________________________

From report at bugs.python.org  Mon Jan  6 20:45:39 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 07 Jan 2020 01:45:39 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
In-Reply-To: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>
Message-ID: <1578361539.08.0.486246926149.issue39234@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Thanks for the PRs.

----------
nosy: +eric.smith
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39234>
_______________________________________

From report at bugs.python.org  Mon Jan  6 21:11:43 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 07 Jan 2020 02:11:43 +0000
Subject: [issue39236] [venv] Adding a .gitignore file to virtual environments
In-Reply-To: <1578339905.74.0.21964655851.issue39236@roundup.psfhosted.org>
Message-ID: <1578363103.11.0.703483803017.issue39236@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
nosy: +Anthony Sottile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39236>
_______________________________________

From report at bugs.python.org  Mon Jan  6 21:36:42 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 07 Jan 2020 02:36:42 +0000
Subject: [issue22606] Inconsistency between Python 2 and PyPy regarding future
 imports
In-Reply-To: <1412974125.28.0.470692866106.issue22606@psf.upfronthosting.co.za>
Message-ID: <1578364602.9.0.430109942001.issue22606@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

If you fully compiled this code, it would fail. CPython checks the well-formedness of __future__ statements after ast parsing.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22606>
_______________________________________

From report at bugs.python.org  Tue Jan  7 00:38:42 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 07 Jan 2020 05:38:42 +0000
Subject: [issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem()
In-Reply-To: <1544525657.6.0.788709270274.issue35459@psf.upfronthosting.co.za>
Message-ID: <1578375522.38.0.709475918335.issue35459@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> I've tried writing some Python code to reproduce this bug, but I'm unable to -- I should be missing something. Is there a simple snippet showing the issue? 


Note that this is a bug from long ago.  Why this bug had lived long is it can not happen in regular cases.  So it is difficult to reproduce.

See PR 11112.  _csv module is changed to use PyDict_GetItemWithError.
Let's try it on Python 3.7.

Python 3.7.6 (default, Dec 30 2019, 19:38:28)
[Clang 11.0.0 (clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> class S(str):
...   def __hash__(self):
...     raise MemoryError
...
>>> import _csv
>>> _csv.Dialect(S("excel"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_csv.Error: unknown dialect

You can see the MemoryError is suppressed.  Let's try it on Python 3.8.

$ python3
Python 3.8.1 (default, Jan  6 2020, 16:02:33)
 (snip)
>>> _csv.Dialect(S("excel"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in __hash__
MemoryError

You can see the MemoryError is not suppressed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35459>
_______________________________________

From report at bugs.python.org  Tue Jan  7 01:42:07 2020
From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_M?=)
Date: Tue, 07 Jan 2020 06:42:07 +0000
Subject: [issue35459] Use PyDict_GetItemWithError() instead of PyDict_GetItem()
In-Reply-To: <1544525657.6.0.788709270274.issue35459@psf.upfronthosting.co.za>
Message-ID: <1578379327.46.0.766970468879.issue35459@roundup.psfhosted.org>


Rapha?l M <raphael.monat at lip6.fr> added the comment:

Thank you very much!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35459>
_______________________________________

From report at bugs.python.org  Tue Jan  7 02:28:05 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 07 Jan 2020 07:28:05 +0000
Subject: [issue39242] Update news.gmane.org to news.gmane.io
Message-ID: <1578382085.09.0.293761800021.issue39242@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

https://discuss.python.org/t/ot-gmane-server-moving/2967

AFAIK, we have several codes that use news.gmane.org.
According to article, don't we have to update it?
(sorry I am not a committer, so I don't have permission to write on that)

https://github.com/python/cpython/search?q=news.gmane.org&unscoped_q=news.gmane.org

----------
messages: 359491
nosy: corona10, pitrou
priority: normal
severity: normal
status: open
title: Update news.gmane.org to news.gmane.io

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39242>
_______________________________________

From report at bugs.python.org  Tue Jan  7 02:31:40 2020
From: report at bugs.python.org (Batuhan)
Date: Tue, 07 Jan 2020 07:31:40 +0000
Subject: [issue37537] Compute allocated blocks in _Py_GetAllocatedBlocks()
In-Reply-To: <1562740079.69.0.103809665288.issue37537@roundup.psfhosted.org>
Message-ID: <1578382300.36.0.57621833067.issue37537@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Anything left on this issue, PR 14680 looks resolved this issue.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37537>
_______________________________________

From report at bugs.python.org  Tue Jan  7 02:41:59 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 07 Jan 2020 07:41:59 +0000
Subject: [issue37537] Compute allocated blocks in _Py_GetAllocatedBlocks()
In-Reply-To: <1562740079.69.0.103809665288.issue37537@roundup.psfhosted.org>
Message-ID: <1578382919.8.0.132443410202.issue37537@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37537>
_______________________________________

From report at bugs.python.org  Tue Jan  7 02:58:46 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 07 Jan 2020 07:58:46 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578383926.56.0.655134496593.issue38623@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset ca94677a6216e2d41b04574986ce49d31a0b329c by Inada Naoki in branch 'master':
bpo-38623: Doc: Add section for site module CLI. (GH-17858)
https://github.com/python/cpython/commit/ca94677a6216e2d41b04574986ce49d31a0b329c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38623>
_______________________________________

From report at bugs.python.org  Tue Jan  7 02:58:52 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jan 2020 07:58:52 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578383932.9.0.49563676059.issue38623@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17300
pull_request: https://github.com/python/cpython/pull/17890

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38623>
_______________________________________

From report at bugs.python.org  Tue Jan  7 02:58:59 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jan 2020 07:58:59 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578383939.18.0.246185445129.issue38623@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17301
pull_request: https://github.com/python/cpython/pull/17891

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38623>
_______________________________________

From report at bugs.python.org  Tue Jan  7 03:04:38 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jan 2020 08:04:38 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578384278.4.0.498702565327.issue38623@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 72995c5cdd7ad4af6252bbe129e8fc63f5006130 by Miss Islington (bot) in branch '3.7':
bpo-38623: Doc: Add section for site module CLI. (GH-17858)
https://github.com/python/cpython/commit/72995c5cdd7ad4af6252bbe129e8fc63f5006130


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38623>
_______________________________________

From report at bugs.python.org  Tue Jan  7 03:04:47 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jan 2020 08:04:47 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578384287.09.0.108735133109.issue38623@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a6b37589a05c63abec122d3a00785641a3bcd85a by Miss Islington (bot) in branch '3.8':
bpo-38623: Doc: Add section for site module CLI. (GH-17858)
https://github.com/python/cpython/commit/a6b37589a05c63abec122d3a00785641a3bcd85a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38623>
_______________________________________

From report at bugs.python.org  Tue Jan  7 03:20:10 2020
From: report at bugs.python.org (Manish)
Date: Tue, 07 Jan 2020 08:20:10 +0000
Subject: [issue30717] Add unicode grapheme cluster break algorithm
In-Reply-To: <1497986122.28.0.540580196076.issue30717@psf.upfronthosting.co.za>
Message-ID: <1578385210.83.0.540858035312.issue30717@roundup.psfhosted.org>


Manish <manishsmail at gmail.com> added the comment:

> Does `unicode-segmentation` support all platforms that CPython supports?

It's no-std, so it supports everything the base Rust compiler supports (which is basically everything llvm supports).

And yeah, if there's something that doesn't match with the support matrix this isn't going to work. 


However, I suggested this more for the potential PyPI package. If you're working this into CPython you'd have to figure out how best to include Rust stuff in your build system, which seems like a giant chunk of scope creep :)



For including in CPython I'd suggest looking through unicode-segmentation and writing a C version of it. We use a python script[1] to generate the data tables, this might be something y'all can use. Swift's UAX 29 implementation is also quite interesting, however it's baked in deeply to the language so it's less useful as a starting point.


 [1]: https://github.com/unicode-rs/unicode-segmentation/blob/master/scripts/unicode.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30717>
_______________________________________

From report at bugs.python.org  Tue Jan  7 03:23:48 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 07 Jan 2020 08:23:48 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578385428.12.0.150758263514.issue38623@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

It is tempting that putting some paragraphs to the tutorial when you think "this should be documented!" but there is no good place in the library reference.

HOWTOs is the document for advanced topics.  But it doesn't cover wide area yet.  There is no topic about module search path or site-packages.

Since the tutorial covers a wide area, including module, it is very tempting to add many random notes about module.

But please remember that the primary reader is people new to Python.  (I learned Python 2.4 by the tutorial!)

The reader has learned Python syntax and basic types in chapters 1~5 and now learning how to split a Python program into multiple files.

So please don't try to answer the question in Stackoverflow in the tutorial, unless it is worth enough for the reader.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38623>
_______________________________________

From report at bugs.python.org  Tue Jan  7 03:26:54 2020
From: report at bugs.python.org (Batuhan)
Date: Tue, 07 Jan 2020 08:26:54 +0000
Subject: [issue36553] inspect.is_decorator_call(frame)
In-Reply-To: <1554711715.55.0.758701327001.issue36553@roundup.psfhosted.org>
Message-ID: <1578385614.69.0.937367772365.issue36553@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36553>
_______________________________________

From report at bugs.python.org  Tue Jan  7 04:01:14 2020
From: report at bugs.python.org (Anthony Wee)
Date: Tue, 07 Jan 2020 09:01:14 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578387674.56.0.7854098423.issue29778@roundup.psfhosted.org>


Anthony Wee <antxwee at gmail.com> added the comment:

Thank you Steve!

I'm still seeing python3.dll being loaded from \DLLs\python3.dll.

_Py_CheckPython3() uses Py_GetPrefix() as a prefix for \DLLs\python3.dll.

It looks like Py_SetPath() sets the _Py_path_config.prefix to "", but I'm not seeing anything else set it to a real value?

https://github.com/python/cpython/blob/7b79dc9200a19ecbac667111dffd58e314be02a8/Python/pathconfig.c#L508

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Tue Jan  7 04:08:20 2020
From: report at bugs.python.org (Batuhan)
Date: Tue, 07 Jan 2020 09:08:20 +0000
Subject: [issue12782] Multiple context expressions do not support parentheses
 for continuation across lines
In-Reply-To: <1313719817.79.0.828403712604.issue12782@psf.upfronthosting.co.za>
Message-ID: <1578388100.21.0.502732974522.issue12782@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12782>
_______________________________________

From report at bugs.python.org  Tue Jan  7 04:13:21 2020
From: report at bugs.python.org (Yorkie Liu)
Date: Tue, 07 Jan 2020 09:13:21 +0000
Subject: [issue39138] import a pycapsule object that's attached on many modules
In-Reply-To: <1577358841.1.0.469176020389.issue39138@roundup.psfhosted.org>
Message-ID: <1578388401.05.0.714136697081.issue39138@roundup.psfhosted.org>


Yorkie Liu <yorkiefixer at gmail.com> added the comment:

Ping Python Team.

----------
resolution: remind -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39138>
_______________________________________

From report at bugs.python.org  Tue Jan  7 05:27:23 2020
From: report at bugs.python.org (Batuhan)
Date: Tue, 07 Jan 2020 10:27:23 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1578392843.63.0.258174266651.issue38870@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

ExtSlice nodes without second value doesn't roundtrip properly

source: x[1:2,]
         Expr(
             value=Subscript(
                 value=Name(id='x', ctx=Load()),
-                slice=ExtSlice(
-                    dims=[
-                        Slice(
-                            lower=Constant(value=1, kind=None),
-                            upper=Constant(value=2, kind=None),
-                            step=None)]),
+                slice=Slice(
+                    lower=Constant(value=1, kind=None),
+                    upper=Constant(value=2, kind=None),
+                    step=None),
                 ctx=Load()))],
     type_ignores=[])

(I have a fix for unifying both tuple, constant tuple and extslice dims traversing)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Tue Jan  7 05:53:45 2020
From: report at bugs.python.org (David Heffernan)
Date: Tue, 07 Jan 2020 10:53:45 +0000
Subject: [issue39243] CDLL __init__ no longer supports name being passed as
 None when the handle is not None
Message-ID: <1578394425.89.0.0381750651285.issue39243@roundup.psfhosted.org>


New submission from David Heffernan <david.heff at gmail.com>:

When creating an instance of CDLL (or indeed WinDLL) for a DLL that is already loaded, you pass the HMODULE in the handle argument to the constructor.

In older versions of ctypes you could pass None as the name argument when doing so. However, the changes in https://github.com/python/cpython/commit/2438cdf0e932a341c7613bf4323d06b91ae9f1f1 now mean that such code fails with a NoneType is not iterable error.

The relevant change is in __init__ for CDLL. The code inside the if _os.name == "nt" block sets up mode, but this is pointless is handle is not None. Because the mode variable is never used, rightly so because the DLL is already loaded.

The issue could be resolved by changing

if _os.name == "nt":

to

if _os.name == "nt" and handle is not None:


The following program demonstrates the issue:

import ctypes

handle = ctypes.windll.kernel32._handle
print(handle)
lib = ctypes.WinDLL(name=None, handle=handle)
print(lib._handle)

This runs to completion in Python 3.7 and earlier, but fails in Python 3.8 and later:

Traceback (most recent call last):
  File "test.py", line 5, in <module>
    lib = ctypes.WinDLL(name=None, handle=handle)
  File "C:\Program Files (x86)\Python\38\lib\ctypes\__init__.py", line 359, in __init__
    if '/' in name or '\\' in name:
TypeError: argument of type 'NoneType' is not iterable

----------
components: Windows, ctypes
messages: 359501
nosy: David Heffernan, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: CDLL __init__ no longer supports name being passed as None when the handle is not None
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39243>
_______________________________________

From report at bugs.python.org  Tue Jan  7 06:04:43 2020
From: report at bugs.python.org (Batuhan)
Date: Tue, 07 Jan 2020 11:04:43 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1578395083.25.0.0868539488991.issue38870@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
pull_requests: +17302
pull_request: https://github.com/python/cpython/pull/17892

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Tue Jan  7 06:25:15 2020
From: report at bugs.python.org (Batuhan)
Date: Tue, 07 Jan 2020 11:25:15 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1578396315.01.0.12206591729.issue38870@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

We might need to tweak the documentation @pablogsal, 

> Unparse an ast.AST object and generate a string with code that would produce an equivalent ast.AST object if parsed back with ast.parse().

If I interpret `equivalent` correctly, this explanation is false under cases like constant nodes has an immutable container value (which they can). 

>>> def wrap(expr):
...     return ast.Module(body=[ast.Expr(expr)], type_ignores=[])
... 
>>> constant_tuple = wrap(ast.Constant(value=(1, 2, 3), kind=None))
>>> normalpy_tuple = ast.parse("(1, 2, 3)")
>>> ast.unparse(constant_tuple) == ast.unparse(normalpy_tuple)
True
>>> ast.dump(ast.parse(ast.unparse(constant_tuple))) != ast.dump(constant_tuple)
True
>>> ast.dump(ast.parse(ast.unparse(constant_tuple))) == ast.dump(normalpy_tuple)
True

This isn't a bug in the code because there is no way we can generate a string that can produce a constant tuple. But this makes the docstring false, at least in certain cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Tue Jan  7 06:54:47 2020
From: report at bugs.python.org (Stefan Holek)
Date: Tue, 07 Jan 2020 11:54:47 +0000
Subject: [issue39244] multiprocessing.get_all_start_methods() wrong default on
 macOS
Message-ID: <1578398087.26.0.562792969059.issue39244@roundup.psfhosted.org>


New submission from Stefan Holek <stefan at epy.co.at>:

In Python 3.8 the default start method has changed from fork to spawn on macOS.
https://docs.python.org/3/whatsnew/3.8.html#multiprocessing

get_all_start_methods() says: "Returns a list of the supported start methods, the first of which is the default."
https://docs.python.org/3/library/multiprocessing.html?highlight=finalize#multiprocessing.get_all_start_methods

However, it appears to still return fork as default:

  Python 3.8.1 (default, Dec 22 2019, 03:45:23) 
  [Clang 10.0.1 (clang-1001.0.46.4)] on darwin
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import multiprocessing
  >>> multiprocessing.get_all_start_methods()
  ['fork', 'spawn', 'forkserver']
  >>> 

Thank you!

----------
components: Library (Lib), macOS
messages: 359503
nosy: ned.deily, ronaldoussoren, stefanholek
priority: normal
severity: normal
status: open
title: multiprocessing.get_all_start_methods() wrong default on macOS
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39244>
_______________________________________

From report at bugs.python.org  Tue Jan  7 07:18:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 12:18:19 +0000
Subject: [issue38502] regrtest: use process groups
In-Reply-To: <1571266006.89.0.625453271604.issue38502@roundup.psfhosted.org>
Message-ID: <1578399499.62.0.128007265818.issue38502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The test_pty has been fixed.

regrtest now calls setsid() when using multiprocessing (-jN), but only in the main branch. It's a nice feature, but I'm not comfortable about backporting it yet. Maybe if tests become too unstable on other branches, we may backport the feature to 3.7 and 3.8.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38502>
_______________________________________

From report at bugs.python.org  Tue Jan  7 07:27:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 12:27:20 +0000
Subject: [issue18969] test suite: enable faulthandler timeout in assert_python
In-Reply-To: <1378633968.54.0.772886567193.issue18969@psf.upfronthosting.co.za>
Message-ID: <1578400040.26.0.56142145792.issue18969@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I modified regrtest to use process groups in bpo-38502. It doesn't solve exactly this issue, but it does fix the overall problem of leaking running processes when a test fails for various reasons. For example, when using regrtest in multiprocessing (-jN) mode), if a test times out, child processes of this test will now be killed.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18969>
_______________________________________

From report at bugs.python.org  Tue Jan  7 07:36:10 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 07 Jan 2020 12:36:10 +0000
Subject: [issue39245] Public API for Vectorcall (PEP 590)
Message-ID: <1578400570.24.0.962646656542.issue39245@roundup.psfhosted.org>


New submission from Petr Viktorin <encukou at gmail.com>:

As per PEP 590, in Python 3.9 the Vectorcall API will be public, i.e. without leading underscores.

----------
messages: 359506
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: Public API for Vectorcall (PEP 590)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39245>
_______________________________________

From report at bugs.python.org  Tue Jan  7 07:36:29 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 07 Jan 2020 12:36:29 +0000
Subject: [issue36974] Implement PEP 590
In-Reply-To: <1559154718.16.0.347735090162.issue36974@roundup.psfhosted.org>
Message-ID: <1578400589.67.0.56240871041.issue36974@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

issue39245 tracks making the API public in Python 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36974>
_______________________________________

From report at bugs.python.org  Tue Jan  7 07:36:35 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 07 Jan 2020 12:36:35 +0000
Subject: [issue39245] Public API for Vectorcall (PEP 590)
In-Reply-To: <1578400570.24.0.962646656542.issue39245@roundup.psfhosted.org>
Message-ID: <1578400595.96.0.423280938128.issue39245@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
components: +C API
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39245>
_______________________________________

From report at bugs.python.org  Tue Jan  7 07:45:10 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 07 Jan 2020 12:45:10 +0000
Subject: [issue39245] Public API for Vectorcall (PEP 590)
In-Reply-To: <1578400570.24.0.962646656542.issue39245@roundup.psfhosted.org>
Message-ID: <1578401110.85.0.905281301225.issue39245@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
keywords: +patch
pull_requests: +17303
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17893

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39245>
_______________________________________

From report at bugs.python.org  Tue Jan  7 07:45:47 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Jan 2020 12:45:47 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1578401147.71.0.584725027569.issue38870@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>  We might need to tweak the documentation @pablogsal, 

Maybe we can say that is 'as close as possible' if you pass an arbitrary AST object (if only happens with Constants we could documment exactly that). Let me think about this and I will make PR updating the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Tue Jan  7 08:23:08 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jan 2020 13:23:08 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578403388.76.0.140774314901.issue39191@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 10ac0cded26d91c3468e5e5a87cecad7fc0bcebd by Miss Islington (bot) (Andrew Svetlov) in branch 'master':
bpo-39191: Fix RuntimeWarning in asyncio test (GH-17863)
https://github.com/python/cpython/commit/10ac0cded26d91c3468e5e5a87cecad7fc0bcebd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39191>
_______________________________________

From report at bugs.python.org  Tue Jan  7 08:23:48 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 07 Jan 2020 13:23:48 +0000
Subject: [issue39161] Py_NewInterpreter docs need updating for multi-phase
 initialization
In-Reply-To: <1577683127.59.0.69655210791.issue39161@roundup.psfhosted.org>
Message-ID: <1578403428.63.0.586002302438.issue39161@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Thanks for the report. I'll draft something better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39161>
_______________________________________

From report at bugs.python.org  Tue Jan  7 08:25:47 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 07 Jan 2020 13:25:47 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578403547.95.0.705515865294.issue39191@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +17304
pull_request: https://github.com/python/cpython/pull/17894

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39191>
_______________________________________

From report at bugs.python.org  Tue Jan  7 08:28:24 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 07 Jan 2020 13:28:24 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578403704.49.0.0376726060974.issue39191@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
pull_requests: +17305
pull_request: https://github.com/python/cpython/pull/17895

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39191>
_______________________________________

From report at bugs.python.org  Tue Jan  7 08:38:59 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 07 Jan 2020 13:38:59 +0000
Subject: [issue38209] Simplify dataclasses.InitVar by using __class_getitem__()
In-Reply-To: <1568788237.84.0.300342046917.issue38209@roundup.psfhosted.org>
Message-ID: <1578404339.43.0.705289048034.issue38209@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38209>
_______________________________________

From report at bugs.python.org  Tue Jan  7 09:00:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 14:00:06 +0000
Subject: [issue39239] select.epoll.unregister(fd) should not ignore EBADF
In-Reply-To: <1578353688.24.0.722884378041.issue39239@roundup.psfhosted.org>
Message-ID: <1578405606.12.0.867857185845.issue39239@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 5b23f7618d434f3000bde482233c8642a6eb2c67 by Victor Stinner in branch 'master':
bpo-39239: epoll.unregister() no longer ignores EBADF (GH-17882)
https://github.com/python/cpython/commit/5b23f7618d434f3000bde482233c8642a6eb2c67


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39239>
_______________________________________

From report at bugs.python.org  Tue Jan  7 09:36:26 2020
From: report at bugs.python.org (Felipe A. Hernandez)
Date: Tue, 07 Jan 2020 14:36:26 +0000
Subject: [issue39246] shutil.rmtree is inefficient because of using os.scandir
 instead of os.walk
Message-ID: <1578407786.88.0.0183603543979.issue39246@roundup.psfhosted.org>


New submission from Felipe A. Hernandez <ergoithz at gmail.com>:

os.rmtree has fd-based symlink replacement protection when iterating with scandir (after bpo-28564).

This logic could be greatly simplified simply by os.fwalk in supported platforms, which already implements a similar (maybe safer) protection.

----------
components: Library (Lib)
messages: 359512
nosy: Felipe A. Hernandez
priority: normal
severity: normal
status: open
title: shutil.rmtree is inefficient because of using os.scandir instead of os.walk
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/issue39246>
_______________________________________

From report at bugs.python.org  Tue Jan  7 09:55:22 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 07 Jan 2020 14:55:22 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578408922.9.0.386205431003.issue39191@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 4112a3da2e01ecc19e9f54b8ac7b383b6f5e85c8 by Andrew Svetlov in branch '3.8':
[3.8] bpo-39191: Fix RuntimeWarning in asyncio test (GH-17863) (#17894)
https://github.com/python/cpython/commit/4112a3da2e01ecc19e9f54b8ac7b383b6f5e85c8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39191>
_______________________________________

From report at bugs.python.org  Tue Jan  7 09:55:35 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 07 Jan 2020 14:55:35 +0000
Subject: [issue39191] Coroutine is awaited despite an exception in
 run_until_complete()
In-Reply-To: <1577972058.72.0.902060082647.issue39191@roundup.psfhosted.org>
Message-ID: <1578408935.16.0.491089886929.issue39191@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39191>
_______________________________________

From report at bugs.python.org  Tue Jan  7 10:40:25 2020
From: report at bugs.python.org (Philippe Ombredanne)
Date: Tue, 07 Jan 2020 15:40:25 +0000
Subject: =?utf-8?q?=5Bissue34723=5D_lower=28=29_on_Turkish_letter_=22=C4=B0=22_ret?=
 =?utf-8?q?urns_a_2-chars-long_string?=
In-Reply-To: <1537279336.26.0.956365154283.issue34723@psf.upfronthosting.co.za>
Message-ID: <1578411625.61.0.242603972563.issue34723@roundup.psfhosted.org>


Philippe Ombredanne <pombredanne at nexb.com> added the comment:

There is a weird thing though (using Python 3.6.8):

>>> [x.lower() for x in '?']
['i?']
>>> [x for x in '?'.lower()]
['i', '?']

I would expect that the results would be the same in both cases. (And this is a source of a bug for some code of mine)

----------
nosy: +pombredanne

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34723>
_______________________________________

From report at bugs.python.org  Tue Jan  7 10:56:48 2020
From: report at bugs.python.org (Michael Hall)
Date: Tue, 07 Jan 2020 15:56:48 +0000
Subject: [issue39232] asyncio crashes when tearing down the proactor event loop
In-Reply-To: <1578335360.75.0.333919607495.issue39232@roundup.psfhosted.org>
Message-ID: <1578412608.91.0.0874640388413.issue39232@roundup.psfhosted.org>


Michael Hall <michael at michaelhall.tech> added the comment:

I don't know if it would be feasible to add this to asyncio, but having a way to mark a resource as needing to be deterministically cleaned up at loop close could probably solve this as well as the underlying reasons why the transports are leaning on __del__ behavior which is an implementation detail (differing on, for example, pypy) and probably improve the overall usefulness of asyncio.run as well.

An addition like that probably requires more discussion than fixing this crash though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39232>
_______________________________________

From report at bugs.python.org  Tue Jan  7 11:05:38 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 07 Jan 2020 16:05:38 +0000
Subject: [issue37194] Move new vector private declarations to the internal C
 API
In-Reply-To: <1559908440.37.0.746705371355.issue37194@roundup.psfhosted.org>
Message-ID: <1578413138.68.0.675433112369.issue37194@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
pull_requests: +17306
pull_request: https://github.com/python/cpython/pull/17896

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37194>
_______________________________________

From report at bugs.python.org  Tue Jan  7 11:27:12 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 07 Jan 2020 16:27:12 +0000
Subject: [issue39226] venv does not include pythonXX.lib
In-Reply-To: <1578264613.69.0.856144088862.issue39226@roundup.psfhosted.org>
Message-ID: <1578414432.74.0.268879751217.issue39226@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The python38.lib file isn't present in any venv, whether created by virtualenv or "python -m venv". I believe the mod_wsgi build process may not cater for building in a venv on Windows.

When created with "python -m venv", a venv contains the file pyvenv.cfg with contents like this:

home = C:\Users\Vinay\AppData\Local\Programs\Python\Python38
include-system-site-packages = false
version = 3.8.1

and the location of python38.lib on this system is given by the libs directory relative to the home value in the above snippet.

I don't think this is a venv bug so I will probably close this issue soon, unless you provide more evidence of an actual problem in the venv package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39226>
_______________________________________

From report at bugs.python.org  Tue Jan  7 11:32:50 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 07 Jan 2020 16:32:50 +0000
Subject: [issue39236] [venv] Adding a .gitignore file to virtual environments
In-Reply-To: <1578339905.74.0.21964655851.issue39236@roundup.psfhosted.org>
Message-ID: <1578414770.11.0.742912795775.issue39236@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'm -0.5 on this. Beginners will probably shoot themselves in the foot multiple ways using git (or any DVCS), in terms of checking things in they didn't mean to (e.g. build artifacts which are not in the venv). As they can easily undo this, I don't think we need to do this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39236>
_______________________________________

From report at bugs.python.org  Tue Jan  7 11:34:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 16:34:52 +0000
Subject: =?utf-8?q?=5Bissue34723=5D_lower=28=29_on_Turkish_letter_=22=C4=B0=22_ret?=
 =?utf-8?q?urns_a_2-chars-long_string?=
In-Reply-To: <1537279336.26.0.956365154283.issue34723@psf.upfronthosting.co.za>
Message-ID: <1578414892.74.0.299919248121.issue34723@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I would expect that the results would be the same in both cases.

It's not. Read again my previous comment.

>>> ["U+%04x" % ord(ch) for ch in "?".lower()]
['U+0069', 'U+0307']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34723>
_______________________________________

From report at bugs.python.org  Tue Jan  7 11:39:34 2020
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 07 Jan 2020 16:39:34 +0000
Subject: =?utf-8?q?=5Bissue34723=5D_lower=28=29_on_Turkish_letter_=22=C4=B0=22_ret?=
 =?utf-8?q?urns_a_2-chars-long_string?=
In-Reply-To: <1537279336.26.0.956365154283.issue34723@psf.upfronthosting.co.za>
Message-ID: <1578415174.91.0.855611672145.issue34723@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

PS: The first entry of the result is a decomposed string, too:

>>> r = [x.lower() for x in '?']
>>> hex(ord(r[0][0]))
'0x69'
>>> hex(ord(r[0][1]))
'0x307'

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34723>
_______________________________________

From report at bugs.python.org  Tue Jan  7 11:40:30 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 07 Jan 2020 16:40:30 +0000
Subject: [issue39198] Lock may not be released in Logger.isEnabledFor
In-Reply-To: <1577995820.85.0.483829284775.issue39198@roundup.psfhosted.org>
Message-ID: <1578415230.43.0.542374815267.issue39198@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 950c6795aa0ffa85e103a13e7a04e08cb34c66ad by Vinay Sajip (Derek Brown) in branch 'master':
bpo-39198: Ensure logging global lock is released on exception in isEnabledFor (GH-17689)
https://github.com/python/cpython/commit/950c6795aa0ffa85e103a13e7a04e08cb34c66ad


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39198>
_______________________________________

From report at bugs.python.org  Tue Jan  7 11:41:20 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jan 2020 16:41:20 +0000
Subject: [issue39198] Lock may not be released in Logger.isEnabledFor
In-Reply-To: <1577995820.85.0.483829284775.issue39198@roundup.psfhosted.org>
Message-ID: <1578415280.31.0.989484437477.issue39198@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17307
pull_request: https://github.com/python/cpython/pull/17897

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39198>
_______________________________________

From report at bugs.python.org  Tue Jan  7 11:41:52 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jan 2020 16:41:52 +0000
Subject: [issue39198] Lock may not be released in Logger.isEnabledFor
In-Reply-To: <1577995820.85.0.483829284775.issue39198@roundup.psfhosted.org>
Message-ID: <1578415312.29.0.701459911373.issue39198@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17308
pull_request: https://github.com/python/cpython/pull/17898

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39198>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:03:30 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 07 Jan 2020 17:03:30 +0000
Subject: [issue39198] Lock may not be released in Logger.isEnabledFor
In-Reply-To: <1577995820.85.0.483829284775.issue39198@roundup.psfhosted.org>
Message-ID: <1578416610.19.0.632792761885.issue39198@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset bff48c6734f936257b0cfae58dbea67d43e3b245 by Vinay Sajip (Miss Islington (bot)) in branch '3.8':
bpo-39198: Ensure logging global lock is released on exception in isEnabledFor (GH-17689) (GH-17897)
https://github.com/python/cpython/commit/bff48c6734f936257b0cfae58dbea67d43e3b245


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39198>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:03:53 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 07 Jan 2020 17:03:53 +0000
Subject: [issue39198] Lock may not be released in Logger.isEnabledFor
In-Reply-To: <1577995820.85.0.483829284775.issue39198@roundup.psfhosted.org>
Message-ID: <1578416633.71.0.405792317101.issue39198@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset d46dec981abdefba56336521c7587c8554bb1b9d by Vinay Sajip (Miss Islington (bot)) in branch '3.7':
bpo-39198: Ensure logging global lock is released on exception in isEnabledFor (GH-17689) (GH-17898)
https://github.com/python/cpython/commit/d46dec981abdefba56336521c7587c8554bb1b9d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39198>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:04:16 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 07 Jan 2020 17:04:16 +0000
Subject: [issue39198] Lock may not be released in Logger.isEnabledFor
In-Reply-To: <1577995820.85.0.483829284775.issue39198@roundup.psfhosted.org>
Message-ID: <1578416656.25.0.500484569121.issue39198@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39198>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:28:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 17:28:16 +0000
Subject: [issue38615] imaplib has no timeout setting
In-Reply-To: <1572271081.51.0.380114547236.issue38615@roundup.psfhosted.org>
Message-ID: <1578418096.66.0.906208203494.issue38615@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 13a7ee8d62dafe7d2291708312fa2a86e171c7fa by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-38615: Add timeout parameter for IMAP4 and IMAP4_SSL constructor (GH-17203)
https://github.com/python/cpython/commit/13a7ee8d62dafe7d2291708312fa2a86e171c7fa


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38615>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:28:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 17:28:49 +0000
Subject: [issue38615] imaplib has no timeout setting
In-Reply-To: <1572271081.51.0.380114547236.issue38615@roundup.psfhosted.org>
Message-ID: <1578418129.92.0.898670638192.issue38615@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Jairo Llopis for the feature request and thanks Dong-hee Na for actually implementing it!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38615>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:31:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 17:31:01 +0000
Subject: [issue38871] lib2to3 generates invalid code with filter and ternary
 operator
In-Reply-To: <1574291556.7.0.332589714744.issue38871@roundup.psfhosted.org>
Message-ID: <1578418261.83.0.442523683122.issue38871@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b821173b5458d137c8d5edb6e9b4997aac800a38 by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-38871: Fix lib2to3 for filter-based statements that contain lambda (GH-17780)
https://github.com/python/cpython/commit/b821173b5458d137c8d5edb6e9b4997aac800a38


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38871>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:31:08 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jan 2020 17:31:08 +0000
Subject: [issue38871] lib2to3 generates invalid code with filter and ternary
 operator
In-Reply-To: <1574291556.7.0.332589714744.issue38871@roundup.psfhosted.org>
Message-ID: <1578418268.57.0.744958888199.issue38871@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17309
pull_request: https://github.com/python/cpython/pull/17899

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38871>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:31:14 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jan 2020 17:31:14 +0000
Subject: [issue38871] lib2to3 generates invalid code with filter and ternary
 operator
In-Reply-To: <1574291556.7.0.332589714744.issue38871@roundup.psfhosted.org>
Message-ID: <1578418274.6.0.869243343523.issue38871@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17310
pull_request: https://github.com/python/cpython/pull/17900

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38871>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:32:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 17:32:59 +0000
Subject: [issue38871] lib2to3 generates invalid code with filter and ternary
 operator
In-Reply-To: <1574291556.7.0.332589714744.issue38871@roundup.psfhosted.org>
Message-ID: <1578418379.86.0.887900248633.issue38871@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Zoran Simic to the bug report, and thanks Dong-hee Na for fixing it.

It's fixed in the master branch and backports to 3.7 and 3.8 will land as soon as the CI tests pass.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38871>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:35:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 17:35:25 +0000
Subject: [issue13601] sys.stderr should be line-buffered when stderr is not a
 TTY
In-Reply-To: <1323868292.46.0.495967266587.issue13601@psf.upfronthosting.co.za>
Message-ID: <1578418525.16.0.735861278327.issue13601@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

So it just took 9 years to fix this old bug :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13601>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:35:37 2020
From: report at bugs.python.org (Michael Robellard)
Date: Tue, 07 Jan 2020 17:35:37 +0000
Subject: [issue39247] dataclass defaults and property don't work together
Message-ID: <1578418537.56.0.0565923550129.issue39247@roundup.psfhosted.org>


New submission from Michael Robellard <mike at robellard.com>:

I ran into a strange issue while trying to use a dataclass together with a property.

I have it down to a minumum to reproduce it:

import dataclasses

@dataclasses.dataclass
class FileObject:
    _uploaded_by: str = dataclasses.field(default=None, init=False)
    uploaded_by: str = None

    def save(self):
        print(self.uploaded_by)

    @property
    def uploaded_by(self):
        return self._uploaded_by

    @uploaded_by.setter
    def uploaded_by(self, uploaded_by):
        print('Setter Called with Value ', uploaded_by)
        self._uploaded_by = uploaded_by

p = FileObject()
p.save()
This outputs:

Setter Called with Value  <property object at 0x7faeb00150b0>
<property object at 0x7faeb00150b0>
I would expect to get None instead

Here is the StackOverflow Question where I started this:
https://stackoverflow.com/questions/59623952/weird-issue-when-using-dataclass-and-property-together

----------
components: Library (Lib)
messages: 359528
nosy: Michael Robellard
priority: normal
severity: normal
status: open
title: dataclass defaults and property don't work together
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39247>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:47:57 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jan 2020 17:47:57 +0000
Subject: [issue38871] lib2to3 generates invalid code with filter and ternary
 operator
In-Reply-To: <1574291556.7.0.332589714744.issue38871@roundup.psfhosted.org>
Message-ID: <1578419277.83.0.676538820199.issue38871@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 535a3c4e3da2f0076bd62f04fb2cc44999fc2419 by Miss Islington (bot) in branch '3.7':
bpo-38871: Fix lib2to3 for filter-based statements that contain lambda (GH-17780)
https://github.com/python/cpython/commit/535a3c4e3da2f0076bd62f04fb2cc44999fc2419


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38871>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:52:11 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 07 Jan 2020 17:52:11 +0000
Subject: [issue38871] lib2to3 generates invalid code with filter and ternary
 operator
In-Reply-To: <1574291556.7.0.332589714744.issue38871@roundup.psfhosted.org>
Message-ID: <1578419531.44.0.386447005073.issue38871@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 39a5c889d30d03a88102e56f03ee0c95db198fb3 by Miss Islington (bot) in branch '3.8':
bpo-38871: Fix lib2to3 for filter-based statements that contain lambda (GH-17780)
https://github.com/python/cpython/commit/39a5c889d30d03a88102e56f03ee0c95db198fb3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38871>
_______________________________________

From report at bugs.python.org  Tue Jan  7 12:54:13 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 07 Jan 2020 17:54:13 +0000
Subject: [issue37194] Move new vector private declarations to the internal C
 API
In-Reply-To: <1559908440.37.0.746705371355.issue37194@roundup.psfhosted.org>
Message-ID: <1578419653.03.0.382546698633.issue37194@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
pull_requests: +17311
pull_request: https://github.com/python/cpython/pull/17893

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37194>
_______________________________________

From report at bugs.python.org  Tue Jan  7 13:12:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 18:12:11 +0000
Subject: [issue39248] test_distutils fails on PPC64 Fedora 3.x
Message-ID: <1578420731.23.0.752143109381.issue39248@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

https://buildbot.python.org/all/#/builders/8/builds/136

0:11:37 load avg: 2.21 [230/420/1] test_distutils failed
Traceback (most recent call last):
  File "/tmp/tmpo2bw8_ak.py", line 5, in <module>
    byte_compile(files, optimize=1, force=None,
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/util.py", line 359, in byte_compile
    import subprocess
  File "/tmp/subprocess.py", line 28
    """Subprocesses with accessible I/O streams

This module allows you to spawn processes, connect to their
input/output/error pipes, and obtain their return codes.

For a complete description of this module see the Python documentation.

Main API
========
call(...): Runs a command, waits for it to complete, then returns
    the return code.
check_call(...): Same as call() but raises CalledProcessError()
    if return code is not 0
check_output(...): Same as check_call() but returns the contents of
    stdout instead of a return code
Popen(...): A class for flexibly executing a command in a new process

Constants
---------
PIPE:    Special value that indicates a pipe should be created
STDOUT:  Special value that indicates that stderr should go to stdout
"""Instruction context:
       ^
SyntaxError: invalid syntax
Traceback (most recent call last):
  File "/tmp/tmpkoui1d2n.py", line 5, in <module>
    byte_compile(files, optimize=1, force=None,
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/util.py", line 359, in byte_compile
    import subprocess
  File "/tmp/subprocess.py", line 28
    """Subprocesses with accessible I/O streams

This module allows you to spawn processes, connect to their
input/output/error pipes, and obtain their return codes.

For a complete description of this module see the Python documentation.

Main API
========
call(...): Runs a command, waits for it to complete, then returns
    the return code.
check_call(...): Same as call() but raises CalledProcessError()
    if return code is not 0
check_output(...): Same as check_call() but returns the contents of
    stdout instead of a return code
Popen(...): A class for flexibly executing a command in a new process

Constants
---------
PIPE:    Special value that indicates a pipe should be created
STDOUT:  Special value that indicates that stderr should go to stdout
"""Instruction context:
       ^
SyntaxError: invalid syntax
error: command '/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/python' failed with exit status 1
error: Bad exit status from /var/tmp/rpm-tmp.yc4Iwj (%install)
    Bad exit status from /var/tmp/rpm-tmp.yc4Iwj (%install)
Traceback (most recent call last):
  File "/tmp/tmp6h6zfdg2.py", line 5, in <module>
    byte_compile(files, optimize=1, force=None,
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/util.py", line 359, in byte_compile
    import subprocess
  File "/tmp/subprocess.py", line 28
    """Subprocesses with accessible I/O streams

This module allows you to spawn processes, connect to their
input/output/error pipes, and obtain their return codes.

For a complete description of this module see the Python documentation.

Main API
========
call(...): Runs a command, waits for it to complete, then returns
    the return code.
check_call(...): Same as call() but raises CalledProcessError()
    if return code is not 0
check_output(...): Same as check_call() but returns the contents of
    stdout instead of a return code
Popen(...): A class for flexibly executing a command in a new process

Constants
---------
PIPE:    Special value that indicates a pipe should be created
STDOUT:  Special value that indicates that stderr should go to stdout
"""Instruction context:
       ^
SyntaxError: invalid syntax
error: command '/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/python' failed with exit status 1
error: Bad exit status from /var/tmp/rpm-tmp.ccdCTP (%install)
    Bad exit status from /var/tmp/rpm-tmp.ccdCTP (%install)
Traceback (most recent call last):
  File "/tmp/tmp_slztuax.py", line 5, in <module>
    byte_compile(files, optimize=1, force=None,
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/util.py", line 359, in byte_compile
    import subprocess
  File "/tmp/subprocess.py", line 28
    """Subprocesses with accessible I/O streams

This module allows you to spawn processes, connect to their
input/output/error pipes, and obtain their return codes.

For a complete description of this module see the Python documentation.

Main API
========
call(...): Runs a command, waits for it to complete, then returns
    the return code.
check_call(...): Same as call() but raises CalledProcessError()
    if return code is not 0
check_output(...): Same as check_call() but returns the contents of
    stdout instead of a return code
Popen(...): A class for flexibly executing a command in a new process

Constants
---------
PIPE:    Special value that indicates a pipe should be created
STDOUT:  Special value that indicates that stderr should go to stdout
"""Instruction context:
       ^
SyntaxError: invalid syntax
test_byte_compile (distutils.tests.test_install_lib.InstallLibTestCase) ... ERROR
(...)
test_no_optimize_flag (distutils.tests.test_bdist_rpm.BuildRpmTestCase) ... ERROR
test_quiet (distutils.tests.test_bdist_rpm.BuildRpmTestCase) ... ERROR
(...)
test_byte_compile_optimized (distutils.tests.test_build_py.BuildPyTestCase) ... ERROR

======================================================================
ERROR: test_byte_compile (distutils.tests.test_install_lib.InstallLibTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/tests/test_install_lib.py", line 46, in test_byte_compile
    cmd.byte_compile([f])
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/command/install_lib.py", line 136, in byte_compile
    byte_compile(files, optimize=self.optimize,
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/util.py", line 425, in byte_compile
    spawn(cmd, dry_run=dry_run)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/spawn.py", line 36, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/spawn.py", line 157, in _spawn_posix
    raise DistutilsExecError(
distutils.errors.DistutilsExecError: command '/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/python' failed with exit status 1

======================================================================
ERROR: test_no_optimize_flag (distutils.tests.test_bdist_rpm.BuildRpmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/tests/test_bdist_rpm.py", line 120, in test_no_optimize_flag
    cmd.run()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/command/bdist_rpm.py", line 363, in run
    self.spawn(rpm_cmd)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/cmd.py", line 365, in spawn
    spawn(cmd, search_path, dry_run=self.dry_run)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/spawn.py", line 36, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/spawn.py", line 157, in _spawn_posix
    raise DistutilsExecError(
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit status 1

======================================================================
ERROR: test_quiet (distutils.tests.test_bdist_rpm.BuildRpmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/tests/test_bdist_rpm.py", line 77, in test_quiet
    cmd.run()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/command/bdist_rpm.py", line 363, in run
    self.spawn(rpm_cmd)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/cmd.py", line 365, in spawn
    spawn(cmd, search_path, dry_run=self.dry_run)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/spawn.py", line 36, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/spawn.py", line 157, in _spawn_posix
    raise DistutilsExecError(
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit status 1

======================================================================
ERROR: test_byte_compile_optimized (distutils.tests.test_build_py.BuildPyTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/tests/test_build_py.py", line 118, in test_byte_compile_optimized
    cmd.run()
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/command/build_py.py", line 95, in run
    self.byte_compile(self.get_outputs(include_bytecode=0))
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/command/build_py.py", line 391, in byte_compile
    byte_compile(files, optimize=self.optimize,
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/util.py", line 425, in byte_compile
    spawn(cmd, dry_run=dry_run)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/spawn.py", line 36, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/Lib/distutils/spawn.py", line 157, in _spawn_posix
    raise DistutilsExecError(
distutils.errors.DistutilsExecError: command '/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64/build/python' failed with exit status 1

----------------------------------------------------------------------

Ran 248 tests in 3.360s

FAILED (errors=4, skipped=29)
test test_distutils failed

----------
components: Distutils, Tests
messages: 359531
nosy: dstufft, eric.araujo, vstinner
priority: normal
severity: normal
status: open
title: test_distutils fails on PPC64 Fedora 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39248>
_______________________________________

From report at bugs.python.org  Tue Jan  7 13:19:06 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 07 Jan 2020 18:19:06 +0000
Subject: [issue39247] dataclass defaults and property don't work together
In-Reply-To: <1578418537.56.0.0565923550129.issue39247@roundup.psfhosted.org>
Message-ID: <1578421146.2.0.975338178832.issue39247@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39247>
_______________________________________

From report at bugs.python.org  Tue Jan  7 13:33:10 2020
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jan 2020 18:33:10 +0000
Subject: [issue23147] Possible error in _header_value_parser.py
In-Reply-To: <1420194679.08.0.467668822135.issue23147@psf.upfronthosting.co.za>
Message-ID: <1578421990.27.0.242702998602.issue23147@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the ping.  Whether or not Serhiy's patch fixed the original problem, the algorithm rewrite has happened so this issue is no longer relevant in any case.

----------
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23147>
_______________________________________

From report at bugs.python.org  Tue Jan  7 13:40:10 2020
From: report at bugs.python.org (R. David Murray)
Date: Tue, 07 Jan 2020 18:40:10 +0000
Subject: [issue23434] support encoded filename in Content-Disposition for HTTP
 in cgi.FieldStorage
In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za>
Message-ID: <1578422410.53.0.398741655115.issue23434@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Are you saying there is no (http) RFC compliant way to fix this, or no way to fix it with the email library parsers?  If the latter, the library is pretty flexible and for internal stdlib use it would probably be permissible to directly call methods in the internal parsing module, if those would be useful.

I haven't re-read the issue to reload my brain, so this question may be off point (except for the first clause of the question).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23434>
_______________________________________

From report at bugs.python.org  Tue Jan  7 14:40:37 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 07 Jan 2020 19:40:37 +0000
Subject: [issue39247] dataclass defaults and property don't work together
In-Reply-To: <1578418537.56.0.0565923550129.issue39247@roundup.psfhosted.org>
Message-ID: <1578426037.62.0.383819758358.issue39247@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39247>
_______________________________________

From report at bugs.python.org  Tue Jan  7 14:42:59 2020
From: report at bugs.python.org (Daniel Pezoa)
Date: Tue, 07 Jan 2020 19:42:59 +0000
Subject: [issue39249] difflib SequenceMatcher 200 char length limitation for
 ratio calculation
Message-ID: <1578426179.61.0.269122492915.issue39249@roundup.psfhosted.org>


New submission from Daniel Pezoa <danieladportas at gmail.com>:

I am using the SequenceMatcher object of the difflib library and I have noticed that a drastic failure occurs when the text strings exceed 200 characters

Source code:
=====================================================================

from difflib import SequenceMatcher

def main():
    # Throw a value of 7% when they are almost equal for having more than 200 characters
    text1 = "aceite y pez hirviendo que vena de la plataforma y de la cual salan tambin muchsimas flechas rodeadas de estopas alquitranadas y encendidas que no podan desprenderse ni arrancarse sin quemarse las manos"
    text2 = "aceite y pedir viendo que vena de la plataforma y de la cual salan tambin muchsimas flechas rodeadas de estopas alquitranadas y encendidas que no podan desprenderse ni arrancarse sin quemarse las manos"
    m = SequenceMatcher(None, text1, text2)
    x = m.ratio()
    porcentaje = (int)(x * 100)
    print("{}\n\n{}\n\n{}\n\nBad: {}%\n\n".format(text1, text2, x, porcentaje))

    # Throw the expected value of 99% for having less than 200 characters
    text1 = "aceite y pez hirviendo que vena de la plataforma y de la cual salan tambin muchsimas flechas rodeadas de estopas alquitranadas y encendidas que no podan desprenderse ni arrancarse sin quemarse las"
    text2 = "aceite y pedir viendo que vena de la plataforma y de la cual salan tambin muchsimas flechas rodeadas de estopas alquitranadas y encendidas que no podan desprenderse ni arrancarse sin quemarse las"
    text1 = "aceite y pez hirviendo que vena de la plataforma y de la cual salan tambin muchsimas flechas rodeadas de estopas alquitranadas"
    text2 = "aceite y pedir viendo que vena de la plataforma y de la cual salan tambin muchsimas flechas rodeadas de estopas alquitranadas"
    m = SequenceMatcher(None, text1, text2)
    x = m.ratio()
    porcentaje = (int)(x * 100)
    print("{}\n\n{}\n\n{}\n\nGood: {}%".format(text1, text2, x, porcentaje))


if __name__== "__main__":
    main()


Output:
======================================================================

aceite y pez hirviendo que vena de la plataforma y de la cual salan tambin muchsimas flechas rodeadas de estopas alquitranadas y encendidas que no podan desprenderse ni arrancarse sin quemarse las manos

aceite y pedir viendo que vena de la plataforma y de la cual salan tambin muchsimas flechas rodeadas de estopas alquitranadas y encendidas que no podan desprenderse ni arrancarse sin quemarse las manos

0.0794044665012407

Bad: 7%


aceite y pez hirviendo que vena de la plataforma y de la cual salan tambin muchsimas flechas rodeadas de estopas alquitranadas

aceite y pedir viendo que vena de la plataforma y de la cual salan tambin muchsimas flechas rodeadas de estopas alquitranadas

0.9800796812749004

Good: 98%

----------
components: Library (Lib)
messages: 359534
nosy: Daniel Pezoa
priority: normal
severity: normal
status: open
title: difflib SequenceMatcher 200 char length limitation for ratio calculation
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39249>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:17:56 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 07 Jan 2020 20:17:56 +0000
Subject: [issue39161] Py_NewInterpreter docs need updating for multi-phase
 initialization
In-Reply-To: <1577683127.59.0.69655210791.issue39161@roundup.psfhosted.org>
Message-ID: <1578428276.0.0.312874466944.issue39161@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
keywords: +patch
pull_requests: +17312
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17896

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39161>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:27:13 2020
From: report at bugs.python.org (Filipp Lepalaan)
Date: Tue, 07 Jan 2020 20:27:13 +0000
Subject: [issue39250] os.path.commonpath() not so common
Message-ID: <1578428833.37.0.29494253109.issue39250@roundup.psfhosted.org>


New submission from Filipp Lepalaan <filipp at mac.com>:

The documentation describes os.path.commonpath() as:

"Return the longest common sub-path of each pathname in the sequence paths. Raise ValueError if paths contain both absolute and relative pathnames, the paths are on the different drives or if paths is empty. Unlike commonprefix(), this returns a valid path."

However, in practice the function seems to always return the *shortest* common path. Steps to reproduce:

import os.path
paths = ['/var', '/var/log', '/var/log/nginx']
os.path.commonpath(paths)

Expected results:
'/var/log'

Actual results:
'/var'

I've tried this with Python 3.5, 3.6, 3.7 and 3.8.1 on both MacOS and Debian/Linux and the results are consistent.

----------
components: Library (Lib)
messages: 359535
nosy: filipp
priority: normal
severity: normal
status: open
title: os.path.commonpath() not so common
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39250>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:28:53 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 07 Jan 2020 20:28:53 +0000
Subject: [issue37194] Move new vector private declarations to the internal C
 API
In-Reply-To: <1559908440.37.0.746705371355.issue37194@roundup.psfhosted.org>
Message-ID: <1578428933.24.0.64656123368.issue37194@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests:  -17306

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37194>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:29:07 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Jan 2020 20:29:07 +0000
Subject: [issue39243] CDLL __init__ no longer supports name being passed as
 None when the handle is not None
In-Reply-To: <1578394425.89.0.0381750651285.issue39243@roundup.psfhosted.org>
Message-ID: <1578428947.14.0.312522074726.issue39243@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Good catch.

We should probably make the line 351 check "if name and ('/' in name ..." like the others in the same function.

----------
keywords: +3.8regression

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39243>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:29:17 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Jan 2020 20:29:17 +0000
Subject: [issue39243] CDLL __init__ no longer supports name being passed as
 None when the handle is not None
In-Reply-To: <1578394425.89.0.0381750651285.issue39243@roundup.psfhosted.org>
Message-ID: <1578428957.79.0.613329921381.issue39243@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +easy, newcomer friendly

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39243>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:33:39 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 07 Jan 2020 20:33:39 +0000
Subject: [issue39250] os.path.commonpath() not so common
In-Reply-To: <1578428833.37.0.29494253109.issue39250@roundup.psfhosted.org>
Message-ID: <1578429219.08.0.664600838345.issue39250@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I'm not seeing how `/var` has `/var/log` in common with `/var/log` and `/var/log/nginx`.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39250>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:34:35 2020
From: report at bugs.python.org (Philippe Ombredanne)
Date: Tue, 07 Jan 2020 20:34:35 +0000
Subject: =?utf-8?q?=5Bissue34723=5D_lower=28=29_on_Turkish_letter_=22=C4=B0=22_ret?=
 =?utf-8?q?urns_a_2-chars-long_string?=
In-Reply-To: <1537279336.26.0.956365154283.issue34723@psf.upfronthosting.co.za>
Message-ID: <1578429275.84.0.204773944655.issue34723@roundup.psfhosted.org>


Philippe Ombredanne <pombredanne at nexb.com> added the comment:

Thank for the (re) explanation. Unicode is tough!
Basically this is the issue i have really in the end with the folding: what used to be a proper alpha string is not longer one after a lower() because the second codepoint is a punctuation and I use a regex split on the \W word class that then behaves differently when the string is lowercased as we have an extra punctuation then to break on. I will find a way around these (rare) cases alright! 

Sorry for the noise.

```
>>> '?'.isalpha()
True
>>> '?'.lower().isalpha()
False
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34723>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:40:10 2020
From: report at bugs.python.org (David Heffernan)
Date: Tue, 07 Jan 2020 20:40:10 +0000
Subject: [issue39243] CDLL __init__ no longer supports name being passed as
 None when the handle is not None
In-Reply-To: <1578394425.89.0.0381750651285.issue39243@roundup.psfhosted.org>
Message-ID: <1578429610.03.0.788300740632.issue39243@roundup.psfhosted.org>


David Heffernan <david.heff at gmail.com> added the comment:

Personally I'd hang this off whether handle has been specified. It seems pointless to set the mode if you are never going to use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39243>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:41:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 20:41:57 +0000
Subject: [issue39239] select.epoll.unregister(fd) should not ignore EBADF
In-Reply-To: <1578353688.24.0.722884378041.issue39239@roundup.psfhosted.org>
Message-ID: <1578429717.64.0.560401315443.issue39239@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39239>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:42:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 20:42:16 +0000
Subject: [issue38870] Expose ast.unparse in the ast module
In-Reply-To: <1574289269.61.0.90605518345.issue38870@roundup.psfhosted.org>
Message-ID: <1578429736.65.0.984721756349.issue38870@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38870>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:42:59 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Jan 2020 20:42:59 +0000
Subject: [issue39243] CDLL __init__ no longer supports name being passed as
 None when the handle is not None
In-Reply-To: <1578394425.89.0.0381750651285.issue39243@roundup.psfhosted.org>
Message-ID: <1578429779.38.0.641090369355.issue39243@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

In that case, we should refactor the init method to check whether handle has been specified earlier, so that it's obvious that the two conditional blocks are never executed in that case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39243>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:43:15 2020
From: report at bugs.python.org (Filipp Lepalaan)
Date: Tue, 07 Jan 2020 20:43:15 +0000
Subject: [issue39250] os.path.commonpath() not so common
In-Reply-To: <1578428833.37.0.29494253109.issue39250@roundup.psfhosted.org>
Message-ID: <1578429795.29.0.0698592913537.issue39250@roundup.psfhosted.org>


Filipp Lepalaan <filipp at mac.com> added the comment:

Hi Zach!

You're absolutely right. Forgive my ignorance. Too much staring at the trees and not seeing the forest (or vice versa).

commonpath() works as advertised. I'm just looking for something different.

Sorry for the false alarm. You can close this issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39250>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:45:15 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 07 Jan 2020 20:45:15 +0000
Subject: [issue39250] os.path.commonpath() not so common
In-Reply-To: <1578428833.37.0.29494253109.issue39250@roundup.psfhosted.org>
Message-ID: <1578429915.72.0.568207133212.issue39250@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

No problem :)

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39250>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:46:23 2020
From: report at bugs.python.org (David Heffernan)
Date: Tue, 07 Jan 2020 20:46:23 +0000
Subject: [issue39243] CDLL __init__ no longer supports name being passed as
 None when the handle is not None
In-Reply-To: <1578429779.38.0.641090369355.issue39243@roundup.psfhosted.org>
Message-ID: <CAP-d_+HVkhM-Ot_UgYHmS1f9oS-_mVUrMS=3j4g2tNF-KaeCjw@mail.gmail.com>


David Heffernan <david.heff at gmail.com> added the comment:

I would approve of that

On Tue, 7 Jan 2020, 20:43 Steve Dower, <report at bugs.python.org> wrote:

>
> Steve Dower <steve.dower at python.org> added the comment:
>
> In that case, we should refactor the init method to check whether handle
> has been specified earlier, so that it's obvious that the two conditional
> blocks are never executed in that case.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39243>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39243>
_______________________________________

From report at bugs.python.org  Tue Jan  7 15:56:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 20:56:18 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578430578.13.0.936151185301.issue29778@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> It looks like Py_SetPath() sets the _Py_path_config.prefix to "", but I'm not seeing anything else set it to a real value?

In the master branch, _Py_CheckPython3() doesn't use _Py_path_config.prefix.

_PyPathConfig_InitDLLPath() calls GetModuleFileNameW(PyWin_DLLhModule, dll_path, MAXPATHLEN) if PyWin_DLLhModule is initialized.

For example, _PyPathConfig_InitDLLPath() is called by Py_Initialize() and Py_SetPath().

PyWin_DLLhModule is initialized by DllMain().

The code in the 3.8 branch looks very similar (I backported my "Remove _PyPathConfig.dll_path" change to 3.8: commit 9f3dcf802eefeb5ab821ce3c7204ab46557d53d7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Tue Jan  7 16:00:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 21:00:20 +0000
Subject: [issue39248] test_distutils fails on PPC64 Fedora 3.x
In-Reply-To: <1578420731.23.0.752143109381.issue39248@roundup.psfhosted.org>
Message-ID: <1578430820.17.0.963499453667.issue39248@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like a change on the worker rather than in the code, since 3.7, 3.8 and master branches are affected.

David Edelsohn: Would you mind to have a look at this issue?

PPC64 Fedora 3.7:
https://buildbot.python.org/all/#builders/32/builds/40

PPC64 Fedora 3.8:
https://buildbot.python.org/all/#/builders/118/builds/70

PPC64 Fedora 3.x:
https://buildbot.python.org/all/#/builders/8/builds/136

----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39248>
_______________________________________

From report at bugs.python.org  Tue Jan  7 16:01:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 21:01:56 +0000
Subject: [issue39248] test_distutils fails on PPC64 Fedora 3.x
In-Reply-To: <1578420731.23.0.752143109381.issue39248@roundup.psfhosted.org>
Message-ID: <1578430916.48.0.969414483336.issue39248@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The problem seems to be that /tmp/subprocess.py file exists: when /tmp/tmpo2bw8_ak.py temporary script was run, /tmp/subprocess.py was used rather than the subprocess of the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39248>
_______________________________________

From report at bugs.python.org  Tue Jan  7 16:02:32 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jan 2020 21:02:32 +0000
Subject: [issue5233] IDLE: exec IDLESTARTUP/PYTHONSTARTUP on restart
In-Reply-To: <1234478082.8.0.463106292983.issue5233@psf.upfronthosting.co.za>
Message-ID: <1578430952.93.0.65586971703.issue5233@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5233>
_______________________________________

From report at bugs.python.org  Tue Jan  7 16:09:06 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 07 Jan 2020 21:09:06 +0000
Subject: [issue39244] multiprocessing.get_all_start_methods() wrong default on
 macOS
In-Reply-To: <1578398087.26.0.562792969059.issue39244@roundup.psfhosted.org>
Message-ID: <1578431346.77.0.898019351674.issue39244@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
components:  -macOS
nosy: +davin, pitrou -ned.deily, ronaldoussoren
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39244>
_______________________________________

From report at bugs.python.org  Tue Jan  7 16:13:42 2020
From: report at bugs.python.org (Brian McKim)
Date: Tue, 07 Jan 2020 21:13:42 +0000
Subject: [issue39251] outdated windows store links in WindowsApps folder
Message-ID: <1578431622.31.0.461218812938.issue39251@roundup.psfhosted.org>


New submission from Brian McKim <bpmckim at gmail.com>:

When I uninstalled the windows store version 3.8 it appears to have placed two links in my \AppData\Local\Microsoft\WindowsApps folder (though they may have always been there), python.exe and python3.exe. When I run these in PowerShell both send me to the 3.7 version in the store. There is a note on the page stating this version is not guaranteed to be stable and points them to the 3.8 version. As these are to make the install as painless as possible these should point to the most stable version; 3.8 in the store.

----------
components: Windows
files: Annotation 2020-01-07 161226.png
messages: 359547
nosy: Brian McKim, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: outdated windows store links in WindowsApps folder
type: enhancement
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48831/Annotation 2020-01-07 161226.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39251>
_______________________________________

From report at bugs.python.org  Tue Jan  7 16:18:26 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 07 Jan 2020 21:18:26 +0000
Subject: [issue39251] outdated windows store links in WindowsApps folder
In-Reply-To: <1578431622.31.0.461218812938.issue39251@roundup.psfhosted.org>
Message-ID: <1578431906.04.0.159254309294.issue39251@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

These links are controlled by Microsoft, and not by us. (Though just to make things confusing, I am the person at Microsoft who can get them updated.)

We've been waiting for the ecosystem to be ready. Too many packages have been failing to install on Python 3.8 for us to want to switch, as we really don't want to drop new Python users into the depths of debugging packaging failures. I need to loop around and find out which ones are still problematic before making the final call.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39251>
_______________________________________

From report at bugs.python.org  Tue Jan  7 16:22:58 2020
From: report at bugs.python.org (Anthony Wee)
Date: Tue, 07 Jan 2020 21:22:58 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578432178.6.0.958601896103.issue29778@roundup.psfhosted.org>


Anthony Wee <antxwee at gmail.com> added the comment:

Hm, I'm seeing _Py_CheckPython3() use Py_GetPrefix(), which uses _Py_path_config.prefix?

https://github.com/python/cpython/blob/c02b41b1fb115c87693530ea6a480b2e15460424/PC/getpathp.c#L1185

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Tue Jan  7 16:23:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 21:23:15 +0000
Subject: [issue23434] support encoded filename in Content-Disposition for HTTP
 in cgi.FieldStorage
In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za>
Message-ID: <1578432195.23.0.500413746388.issue23434@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23434>
_______________________________________

From report at bugs.python.org  Tue Jan  7 16:29:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2020 21:29:23 +0000
Subject: [issue29778] _Py_CheckPython3 uses uninitialized dllpath when
 embedder sets module path with Py_SetPath
In-Reply-To: <1489121898.66.0.224917416789.issue29778@psf.upfronthosting.co.za>
Message-ID: <1578432563.03.0.203112570298.issue29778@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Hm, I'm seeing _Py_CheckPython3() use Py_GetPrefix(), which uses _Py_path_config.prefix?

Oh right, that's the initial issue:

> Later the interpreter tries to load python3.dll and uses dllpath which is empty by default. This empty path gets joined with \python3.dll and \DLLs\python3.dll which is used in the LoadLibraryExW resulting in loading python3.dll from the root location of the windows drive the application is running from.

I reopen the issue.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29778>
_______________________________________

From report at bugs.python.org  Tue Jan  7 16:30:12 2020
From: report at bugs.python.org (Tim Peters)
Date: Tue, 07 Jan 2020 21:30:12 +0000
Subject: [issue39249] difflib SequenceMatcher 200 char length limitation for
 ratio calculation
In-Reply-To: <1578426179.61.0.269122492915.issue39249@roundup.psfhosted.org>
Message-ID: <1578432612.19.0.937490429205.issue39249@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Try passing

    autojunk=False

to the SequenceMatcher constructor.

More on that here:

    https://bugs.python.org/issue31889

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39249>
_______________________________________

From report at bugs.python.org  Tue Jan  7 17:04:15 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jan 2020 22:04:15 +0000
Subject: [issue24815] On maxOS, IDLE app menu can become nearly blank
In-Reply-To: <1438921524.87.0.36411577411.issue24815@psf.upfronthosting.co.za>
Message-ID: <1578434655.18.0.657019211824.issue24815@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The nearly blank menu has the Apple icon and the IDLE dropdown.  I verified that this can be generated with either Debugger or IDLE Help, which are non-modal non-menu windows.

Currently, IDLE has a separate menu for each editor and output and the shell. On macOS, focusing on a menu window pastes that windows menu onto the app menu.  Focusing on a non-menu window leaves the app menu alone, leaving most items linked to the menu window that had the previous focus.  It is not especially good that a majority of menu items do not apply to the current focused window.

Closing a menu window whose menu is currently the app menu removes all but IDLE from the app menu.  Closing any window shifts focus, by default, back to the previous focused window.  So if an app menu window is closed and the previous window is not a menu window, the app menu is cleared and not re-painted.

The nearly blank menu looks odd, but is easily restored by focusing on a menu window.  To fix it anyway, we would have to explicitly focus on a remaining menu window when one is closed.  Or wait until IDLE's menus system is re-factored in such a way that blanking never occurs.

----------
assignee:  -> terry.reedy
nosy:  -kbk, roger.serwy
title: IDLE can lose menubar on OS X -> On maxOS, IDLE app menu can become nearly blank
versions: +Python 3.9 -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24815>
_______________________________________

From report at bugs.python.org  Tue Jan  7 17:12:03 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jan 2020 22:12:03 +0000
Subject: [issue24817] IDLE: disable format menu items when not applicable
In-Reply-To: <1438922216.82.0.623288828961.issue24817@psf.upfronthosting.co.za>
Message-ID: <1578435123.72.0.716718793043.issue24817@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The default selection is, now at least, the current line, so that every entry is always applicable.

----------
assignee:  -> terry.reedy
nosy:  -kbk, roger.serwy
resolution:  -> works for me
stage:  -> resolved
status: open -> closed
title: disable format menu items when not applicable -> IDLE: disable format menu items when not applicable
versions: +Python 3.9 -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24817>
_______________________________________

From report at bugs.python.org  Tue Jan  7 17:13:10 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jan 2020 22:13:10 +0000
Subject: [issue24799] IDLE should detect changes to open files by other
 processes
In-Reply-To: <1438801539.3.0.903562604709.issue24799@psf.upfronthosting.co.za>
Message-ID: <1578435190.88.0.965952283132.issue24799@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24799>
_______________________________________

From report at bugs.python.org  Tue Jan  7 17:14:08 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jan 2020 22:14:08 +0000
Subject: [issue24818] IDLE:  run program in debugger from edit window
In-Reply-To: <1438922651.24.0.0742005388558.issue24818@psf.upfronthosting.co.za>
Message-ID: <1578435248.8.0.253248886996.issue24818@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
nosy:  -kbk, roger.serwy
title: no way to run program in debugger from edit window -> IDLE:  run program in debugger from edit window
versions: +Python 3.9 -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24818>
_______________________________________

From report at bugs.python.org  Tue Jan  7 17:15:54 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jan 2020 22:15:54 +0000
Subject: [issue24816] IDLE: disable selecting debugger when user code is
 running
In-Reply-To: <1438922050.39.0.00616155269251.issue24816@psf.upfronthosting.co.za>
Message-ID: <1578435354.56.0.82470811426.issue24816@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
stage:  -> needs patch
title: don't allow selecting IDLE debugger menu item when running -> IDLE: disable selecting debugger when user code is running
versions: +Python 3.9 -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24816>
_______________________________________

From report at bugs.python.org  Tue Jan  7 17:19:44 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jan 2020 22:19:44 +0000
Subject: [issue25178] IDLE: search regex errors should be in/attached to
 search dialog
In-Reply-To: <1442687681.31.0.813309084762.issue25178@psf.upfronthosting.co.za>
Message-ID: <1578435584.1.0.345705944915.issue25178@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I like the way that Open Module puts error messages in red under the entry box and allows users to correct without first clicking a modal message away.  I would like to do the same here.

----------
assignee:  -> terry.reedy
nosy:  -kbk, roger.serwy
stage:  -> test needed
versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25178>
_______________________________________

From report at bugs.python.org  Tue Jan  7 17:27:03 2020
From: report at bugs.python.org (Ryan McCampbell)
Date: Tue, 07 Jan 2020 22:27:03 +0000
Subject: [issue39252] email.contentmanager.raw_data_manager bytes handler
 breaks on 7bit cte
Message-ID: <1578436023.85.0.680298303035.issue39252@roundup.psfhosted.org>


New submission from Ryan McCampbell <rmccampbell7 at gmail.com>:

The email.contentmanager.set_bytes_content function which handles bytes content for raw_data_manager fails when passed cte="7bit" with an AttributeError: 'bytes' object has no attribute 'encode'. This is probably not a major use case since bytes are generally not for 7-bit data but the failure is clearly not intentional.

----------
components: Library (Lib)
messages: 359555
nosy: rmccampbell7
priority: normal
severity: normal
status: open
title: email.contentmanager.raw_data_manager bytes handler breaks on 7bit cte
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39252>
_______________________________________

From report at bugs.python.org  Tue Jan  7 17:29:45 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jan 2020 22:29:45 +0000
Subject: [issue21995] Idle: review 'missing' attributes of pseudofiles
In-Reply-To: <1405550850.77.0.279876996055.issue21995@psf.upfronthosting.co.za>
Message-ID: <1578436185.73.0.167180439847.issue21995@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I changed title to 'review' (TextIOBase doc and StringIO as a pure text implementation).

----------
title: Idle: pseudofiles have no buffer attribute. -> Idle: review 'missing' attributes of pseudofiles
versions: +Python 3.9 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21995>
_______________________________________

From report at bugs.python.org  Tue Jan  7 17:36:02 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jan 2020 22:36:02 +0000
Subject: [issue38882] IDLE should not make About be a transient of withdrawn
 root window
In-Reply-To: <1574361681.05.0.359568609621.issue38882@roundup.psfhosted.org>
Message-ID: <1578436562.34.0.33599099754.issue38882@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.7 is EOL.

----------
nosy:  -ronaldoussoren
title: IDLE should not make the about dialog be a transient of the withdrawn root window -> IDLE should not make About be a transient of withdrawn root window
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38882>
_______________________________________

From report at bugs.python.org  Tue Jan  7 17:41:17 2020
From: report at bugs.python.org (Julien Palard)
Date: Tue, 07 Jan 2020 22:41:17 +0000
Subject: [issue39229] library/functions.rst causes translated builds to fail
In-Reply-To: <1578289110.04.0.11997957012.issue39229@roundup.psfhosted.org>
Message-ID: <1578436877.69.0.732934375379.issue39229@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

I've already seen Sphinx giving inconsistent warnings about inconsistent terms references, see https://github.com/sphinx-doc/sphinx/issues/3985.

I would recommand fixing all other warnings in the file first, then tell us how it goes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39229>
_______________________________________

From report at bugs.python.org  Tue Jan  7 17:42:55 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 07 Jan 2020 22:42:55 +0000
Subject: [issue27196] Eliminate 'ThemeChanged' warning when running IDLE tests
In-Reply-To: <1464940807.02.0.170350027457.issue27196@psf.upfronthosting.co.za>
Message-ID: <1578436975.48.0.330735534911.issue27196@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.7 EOL.

Ned, do you still see Themed Changed?  I don't on 3.8 on Macbook. with 10.14 mohave(?)

----------
versions: +Python 3.9 -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27196>
_______________________________________

From report at bugs.python.org  Tue Jan  7 18:18:32 2020
From: report at bugs.python.org (Peter Bittner)
Date: Tue, 07 Jan 2020 23:18:32 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578439112.17.0.507764709122.issue38623@roundup.psfhosted.org>


Peter Bittner <peter.bittner at gmx.net> added the comment:

Python learners deserve to know about "site-packages" and (optionally) "dist-packages". This is a "random note", it's an explanation that is missing in the tutorial.

- Site-packages "is the target directory of manually built Python packages", does someone explain.[4]

- It is the "expected convention for locally installed packages", explains Greg Ward in "Installing Python Modules".[5]

- Their location is only a subset of `sys.path`, as visible from the Python code in the `site` module.[6]

The tutorial currently mentions its special role only briefly [7], saying:

> * The installation-dependent default.

We should explain that part. I'll give it a shot replacing my earlier proposal.


[4] https://stackoverflow.com/questions/31384639/what-is-pythons-site-packages-directory
[5] https://docs.python.org/3.8/install/#modifying-python-s-search-path
[6] https://github.com/python/cpython/blob/master/Lib/site.py#L319-L344
[7] https://docs.python.org/3.8/tutorial/modules.html?highlight=installation-dependent%20default#the-module-search-path

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38623>
_______________________________________

From report at bugs.python.org  Tue Jan  7 18:54:53 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Jan 2020 23:54:53 +0000
Subject: [issue39253] Running the test suite with --junit-xml and -R
 incorrectly reports refleaks
Message-ID: <1578441293.88.0.429793229703.issue39253@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

./python -m test test_list -R : --junit-xml something
0:00:00 load avg: 0.52 Run tests sequentially
0:00:00 load avg: 0.52 [1/1] test_list
beginning 9 repetitions
123456789
.........
test_list leaked [798, 798, 798, 798] references, sum=3192
test_list leaked [345, 345, 345, 345] memory blocks, sum=1380
test_list failed

== Tests result: FAILURE ==

1 test failed:
    test_list

Total duration: 3.4 sec
Tests result: FAILURE

----------
components: Tests
messages: 359561
nosy: pablogsal, steve.dower, vstinner
priority: normal
severity: normal
status: open
title: Running the test suite with --junit-xml and -R incorrectly reports refleaks
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39253>
_______________________________________

From report at bugs.python.org  Tue Jan  7 18:55:26 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 07 Jan 2020 23:55:26 +0000
Subject: [issue39253] Running the test suite with --junit-xml and -R
 incorrectly reports refleaks
In-Reply-To: <1578441293.88.0.429793229703.issue39253@roundup.psfhosted.org>
Message-ID: <1578441326.47.0.331734002081.issue39253@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This is going to be very noisy now that we are using  --junit-xml in the buildbots...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39253>
_______________________________________

From report at bugs.python.org  Tue Jan  7 19:06:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 00:06:28 +0000
Subject: [issue39253] Running the test suite with --junit-xml and -R
 incorrectly reports refleaks
In-Reply-To: <1578441293.88.0.429793229703.issue39253@roundup.psfhosted.org>
Message-ID: <1578441988.19.0.650974642036.issue39253@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh. That explains these strange results on AMD64 RHEL7 Refleaks 3.8:

https://buildbot.python.org/all/#/builders/219/builds/41

 argv: [b'make', b'buildbottest', b'TESTOPTS=-R 3:3 -u-cpu --junit-xml test-results.xml -j10 ${BUILDBOT_TESTOPTS}', b'TESTPYTHONOPTS=', b'TESTTIMEOUT=11700']

...
test_quopri leaked [168, 168, 168] references, sum=504
test_quopri leaked [75, 75, 75] memory blocks, sum=225
1:50:20 load avg: 1.06 Re-running test_future5 in verbose mode
test_future5 leaked [42, 42, 42] references, sum=126
test_future5 leaked [20, 20, 20] memory blocks, sum=60
...

The previous build is successful and it didn't use --junit-xml option:

https://buildbot.python.org/all/#/builders/219/builds/40

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39253>
_______________________________________

From report at bugs.python.org  Tue Jan  7 19:32:39 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 08 Jan 2020 00:32:39 +0000
Subject: [issue39247] dataclass defaults and property don't work together
In-Reply-To: <1578418537.56.0.0565923550129.issue39247@roundup.psfhosted.org>
Message-ID: <1578443559.72.0.588037784068.issue39247@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Your code basically becomes similar to this:

sentinel = object()

class FileObject:
    _uploaded_by: str = None
    uploaded_by = None

    def __init__(self, uploaded_by=sentinel):
        if uploaded_by is sentinel:
            self.uploaded_by = FileObject.uploaded_by
        else:
            self.uploaded_by = uploaded_by

    def save(self):
        print(self.uploaded_by)

    @property
    def uploaded_by(self):
        return self._uploaded_by

    @uploaded_by.setter
    def uploaded_by(self, uploaded_by):
        print('Setter Called with Value ', uploaded_by)
        self._uploaded_by = uploaded_by

Which has the same problem. I'll have to give it some thought.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39247>
_______________________________________

From report at bugs.python.org  Tue Jan  7 20:52:07 2020
From: report at bugs.python.org (Carmen Bianca Bakker)
Date: Wed, 08 Jan 2020 01:52:07 +0000
Subject: [issue35163] locale: setlocale(..., 'eo') sets non-existing locale
In-Reply-To: <1541346877.51.0.788709270274.issue35163@psf.upfronthosting.co.za>
Message-ID: <1578448327.1.0.714647205029.issue35163@roundup.psfhosted.org>


Change by Carmen Bianca Bakker <carmenbianca at fedoraproject.org>:


----------
keywords: +patch
pull_requests: +17313
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17901

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35163>
_______________________________________

From report at bugs.python.org  Wed Jan  8 00:23:17 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 08 Jan 2020 05:23:17 +0000
Subject: [issue39243] CDLL __init__ no longer supports name being passed as
 None when the handle is not None
In-Reply-To: <1578394425.89.0.0381750651285.issue39243@roundup.psfhosted.org>
Message-ID: <1578460997.21.0.759517782436.issue39243@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I'd like to match POSIX here by supporting path-like names. Also, I think it would be cleaner to split out the platform-specific work into a separate _load_library method, like how subprocess.Popen is designed, and to stop pretending that WINAPI LoadLibraryEx is POSIX dlopen. For example:

    if _os.name == "nt":
        import nt as _nt
        from _ctypes import LoadLibrary as _LoadLibrary
        from _ctypes import FUNCFLAG_STDCALL as _FUNCFLAG_STDCALL
        # ...
    else:
        from _ctypes import dlopen as _dlopen

    # ...

    class CDLL:
        # ...
        
        def __init__(self, name, mode=DEFAULT_MODE, handle=None,
                     use_errno=False, use_last_error=False, winmode=None):

            class _FuncPtr(_CFuncPtr):
                _restype_ = self._func_restype_
                _flags_ = self._func_flags_
                if use_errno:
                    _flags_ |= _FUNCFLAG_USE_ERRNO
                if use_last_error:
                    _flags_ |= _FUNCFLAG_USE_LASTERROR

            self._FuncPtr = _FuncPtr
            self._name = name
            if handle is None:
                self._handle = self._load_library(name, mode, winmode)
            else:
                self._handle = handle

        if _os.name == "nt":
            def _load_library(self, name, mode, winmode):
                if winmode is None:
                    winmode = _nt._LOAD_LIBRARY_SEARCH_DEFAULT_DIRS
                if name:
                    name = _os.fsdecode(name)
                    # WINAPI LoadLibrary searches for a DLL if the given name
                    # is not fully qualified with an explicit drive. For POSIX
                    # compatibility, and because the DLL search path no longer
                    # contains the working directory, begin by fully resolving
                    # any name that contains a path separator.
                    if '/' in name or '\\' in name:
                        name = _nt._getfullpathname(name)
                        # Given a fully-qualified DLL name, allow loading
                        # dependents from its directory.
                        winmode |= _nt._LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR
                return _LoadLibrary(name, winmode)

        else:
            def _load_library(self, name, mode, winmode):
                if _sys.platform.startswith("aix"):
                    # When the name contains ".a(" and ends with ")", for example,
                    # "libFOO.a(libFOO.so)" - this is taken to be an 
                    # archive(member) syntax for dlopen(), and the mode is
                    # adjusted. Otherwise, name is presented to dlopen() as a
                    # file argument.
                    if name and name.endswith(")") and ".a(" in name:
                        mode |= _os.RTLD_MEMBER | _os.RTLD_NOW
                return _dlopen(name, mode)

----------
nosy: +eryksun
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39243>
_______________________________________

From report at bugs.python.org  Wed Jan  8 00:57:18 2020
From: report at bugs.python.org (Jonathan Mills)
Date: Wed, 08 Jan 2020 05:57:18 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1578463038.13.0.968216761511.issue22107@roundup.psfhosted.org>


Change by Jonathan Mills <jon at jonmills.net>:


----------
nosy: +Jonathan Mills

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22107>
_______________________________________

From report at bugs.python.org  Wed Jan  8 00:57:39 2020
From: report at bugs.python.org (Jonathan Mills)
Date: Wed, 08 Jan 2020 05:57:39 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1578463059.66.0.172870516726.issue22107@roundup.psfhosted.org>


Change by Jonathan Mills <jon at jonmills.net>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22107>
_______________________________________

From report at bugs.python.org  Wed Jan  8 01:04:29 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 08 Jan 2020 06:04:29 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578463469.55.0.206523498199.issue38623@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> The tutorial currently mentions its special role only briefly [7], saying:
>
>> * The installation-dependent default.
>
> We should explain that part. I'll give it a shot replacing my earlier proposal.

I don't think so.  At there, the tutorial doesn't explain about even standard library.  We shouldn't explain about it there.

It should be explained much later in the tutorial, or document other than the tutorial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38623>
_______________________________________

From report at bugs.python.org  Wed Jan  8 01:25:15 2020
From: report at bugs.python.org (Arkadiusz Miskiewicz Arkadiusz Miskiewicz)
Date: Wed, 08 Jan 2020 06:25:15 +0000
Subject: [issue39254] python shebang in python3 tarball files
Message-ID: <1578464714.96.0.727607440351.issue39254@roundup.psfhosted.org>


New submission from Arkadiusz Miskiewicz				Arkadiusz Miskiewicz <arekm at maven.pl>:

Python 3.8.1 files:

        Lib/encodings/rot_13.py \
        Lib/lib2to3/tests/data/different_encoding.py \
        Lib/lib2to3/tests/data/false_encoding.py \
        Tools/gdb/libpython.py \
        Tools/pynche/pynche \
        Tools/pynche/pynche.pyw \
        Tools/scripts/2to3 \
        Tools/scripts/smelly.py \
        python-gdb.py

are calling python (which often points to python2) while should be calling python3 explicitly (unless python2 is required for using these which would be weird in Python 3 package)

----------
components: Build
messages: 359567
nosy: arekm
priority: normal
severity: normal
status: open
title: python shebang in python3 tarball files
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39254>
_______________________________________

From report at bugs.python.org  Wed Jan  8 01:37:00 2020
From: report at bugs.python.org (Arkadiusz Miskiewicz Arkadiusz Miskiewicz)
Date: Wed, 08 Jan 2020 06:37:00 +0000
Subject: [issue39254] python shebang in python3 tarball files
In-Reply-To: <1578464714.96.0.727607440351.issue39254@roundup.psfhosted.org>
Message-ID: <1578465420.34.0.700761746366.issue39254@roundup.psfhosted.org>


Arkadiusz Miskiewicz				Arkadiusz Miskiewicz <arekm at maven.pl> added the comment:

These look to be python2 files. Since python2 is close to EOL should these be ported to python3?

There are more of these in git:

        Lib/encodings/rot_13.py \
        Lib/lib2to3/tests/data/different_encoding.py \
        Lib/lib2to3/tests/data/false_encoding.py \
        Mac/BuildScript/build-installer.py \
        Modules/_sha3/cleanup.py \
        Objects/typeslots.py \
        Parser/asdl_c.py \
        Python/makeopcodetargets.py \
        Tools/gdb/libpython.py \
        Tools/pynche/pynche \
        Tools/pynche/pynche.pyw \
        Tools/scripts/2to3 \
        Tools/scripts/smelly.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39254>
_______________________________________

From report at bugs.python.org  Wed Jan  8 03:44:16 2020
From: report at bugs.python.org (Kallah)
Date: Wed, 08 Jan 2020 08:44:16 +0000
Subject: [issue39255] Windows and Unix run-time differences
Message-ID: <1578473056.67.0.190561060643.issue39255@roundup.psfhosted.org>


New submission from Kallah <mrsortland at gmail.com>:

In the attached sync.py, running it on windows and Unix (Ubuntu and OSX tested) will grant different results. On windows it will output:
x = 1
x = 2
x = 3
y = 1
x = 4
x = 5
x = 6
x = 7
y = 1
While on ubuntu it will output:
x = 1
x = 2
x = 3
y = 4
x = 4
x = 5
x = 6
x = 7
y = 8

----------
components: Windows
files: sync.py
messages: 359569
nosy: Kallah, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows and Unix run-time differences
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48832/sync.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39255>
_______________________________________

From report at bugs.python.org  Wed Jan  8 03:47:43 2020
From: report at bugs.python.org (Felipe A. Hernandez)
Date: Wed, 08 Jan 2020 08:47:43 +0000
Subject: [issue39246] shutil.rmtree is inefficient because of using os.scandir
 instead of os.walk
In-Reply-To: <1578407786.88.0.0183603543979.issue39246@roundup.psfhosted.org>
Message-ID: <1578473263.83.0.759610536807.issue39246@roundup.psfhosted.org>


Felipe A. Hernandez <ergoithz at gmail.com> added the comment:

After some tests, due the accumulating nature of fwalk, I've just realised it's not very safe for big directories, so I'll be closing this issue.

Alternatively, using py37+ fd based scandir, and dir_fd unlink and rmdir calls would reduce complexity while improving safety.

Sorry for the noise.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39246>
_______________________________________

From report at bugs.python.org  Wed Jan  8 04:41:47 2020
From: report at bugs.python.org (Conrad)
Date: Wed, 08 Jan 2020 09:41:47 +0000
Subject: [issue39256] Exception handler set by set_exception_handler is called
 only when I run coroutine by create_task
Message-ID: <1578476507.18.0.348977530849.issue39256@roundup.psfhosted.org>


New submission from Conrad <conradhch at hotmail.com>:

import asyncio

async def test():
    raise Exception("Something goes wrong")

async def main():
    #Un-comment either 1 of the following 3 lines
    # await test() # will not call exception_handler
    # await asyncio.gather(test()) # will not call exception_handler
    # asyncio.create_task(test()) # will call exception_handler

    await asyncio.sleep(5)

def exception_handler(loop, context):
    exception = context.get("exception", None)
    print("exception_handler", exception)

if __name__ == "__main__":
    loop = asyncio.get_event_loop()
    loop.set_exception_handler(exception_handler)
    loop.run_until_complete(main())
    print("Job done")

----------
components: asyncio
messages: 359571
nosy: asvetlov, conraddd, yselivanov
priority: normal
severity: normal
status: open
title: Exception handler set by set_exception_handler is called only when I run coroutine by create_task
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39256>
_______________________________________

From report at bugs.python.org  Wed Jan  8 04:48:51 2020
From: report at bugs.python.org (=?utf-8?q?Antonio_V=C3=A1zquez_Blanco?=)
Date: Wed, 08 Jan 2020 09:48:51 +0000
Subject: [issue39226] venv does not include pythonXX.lib
In-Reply-To: <1578264613.69.0.856144088862.issue39226@roundup.psfhosted.org>
Message-ID: <1578476931.11.0.331080848552.issue39226@roundup.psfhosted.org>


Antonio V?zquez Blanco <antoniovazquezblanco at gmail.com> added the comment:

If that is the intended way to proceed then I will patch mod_wsgi.

Sorry for the inconvenience and thank you very much for the pointers.

Thanks!

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39226>
_______________________________________

From report at bugs.python.org  Wed Jan  8 04:57:10 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 08 Jan 2020 09:57:10 +0000
Subject: [issue39255] Windows and Unix run-time differences
In-Reply-To: <1578473056.67.0.190561060643.issue39255@roundup.psfhosted.org>
Message-ID: <1578477430.05.0.186510053963.issue39255@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I'm sorry, but perhaps I may have missed something here. The behaviour you show is what I would expect. In fact, I would expect that any two runs of your code will likely produce different output, even on the same machine using the same OS. I just ran it twice in Python 3.5 and got different results on the same machine:

    Run 1           Run 2
    x = 1           x = 1
    x = 2           x = 2
    x = 3           x = 3
    x = 4           x = 4
    y = 5           y = 5
    x = 5           x = 5
    x = 6           x = 6
    x = 7           x = 7
    x = 8           y = 8
    y = 9           x = 8
    x = 9           x = 9


You are running code concurrently in multiple processes. The order that the results are printed is unpredictable and will depend on many factors, including the OS.

Can you give any reasons why you consider this is to be a bug rather than normal behaviour?

I'm not going to close this as "Not a bug", since I'm not a multiprocessing expert and I may have misunderstood something, but it looks to me like normal behaviour when using threading or multiprocessing.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39255>
_______________________________________

From report at bugs.python.org  Wed Jan  8 05:17:48 2020
From: report at bugs.python.org (Kallah)
Date: Wed, 08 Jan 2020 10:17:48 +0000
Subject: [issue39255] Windows and Unix run-time differences
In-Reply-To: <1578473056.67.0.190561060643.issue39255@roundup.psfhosted.org>
Message-ID: <1578478668.25.0.429996946382.issue39255@roundup.psfhosted.org>


Kallah <mrsortland at gmail.com> added the comment:

The difference here is that on Windows y will never change, it will stay 1 forever while on Unix systems y will increment. Having done a bit more research it seems this is due to the way multiprocessing works on Windows vs Unix systems. In unix systems the new thread is a fork of the parent while in Windows it is a whole new process built from scratch (if I am understanding it correctly). I am not going to close it as I am unsure if it is by design that Windows and Unix python acts differently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39255>
_______________________________________

From report at bugs.python.org  Wed Jan  8 05:34:34 2020
From: report at bugs.python.org (Ron Serruya)
Date: Wed, 08 Jan 2020 10:34:34 +0000
Subject: [issue39257] contextvars.Context.run hangs forever in
 ProccessPoolExecutor
Message-ID: <1578479674.06.0.280894954081.issue39257@roundup.psfhosted.org>


New submission from Ron Serruya <ron.serruya at gmail.com>:

Sending Context.run to another process via ProccessPoolExecutor hangs forever:

```
from contextvars import ContextVar, copy_context
from concurrent.futures import ProcessPoolExecutor
from multiprocessing import Process

var: ContextVar[int] = ContextVar('var',default=None)

if __name__ == '__main__':
    
    # ***** This hangs forever *****
    with ProcessPoolExecutor(max_workers=1) as pp:
        ctx = copy_context()
        pp.submit(ctx.run, list)

    # ****** This throws 'cannot pickle Context' # ***** This hangs forever *****
    ctx = copy_context()
    p = Process(target=ctx.run, args=(list,))
    p.start()
    p.join()
```

python version is 3.8.0
running on Mac OSX 10.15.1

----------
messages: 359575
nosy: ronserruya
priority: normal
severity: normal
status: open
title: contextvars.Context.run hangs forever in ProccessPoolExecutor
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39257>
_______________________________________

From report at bugs.python.org  Wed Jan  8 05:37:29 2020
From: report at bugs.python.org (Ron Serruya)
Date: Wed, 08 Jan 2020 10:37:29 +0000
Subject: [issue39257] contextvars.Context.run hangs forever in
 ProccessPoolExecutor
In-Reply-To: <1578479674.06.0.280894954081.issue39257@roundup.psfhosted.org>
Message-ID: <1578479849.59.0.361634821892.issue39257@roundup.psfhosted.org>


Ron Serruya <ron.serruya at gmail.com> added the comment:

Sending Context.run to another process via ProccessPoolExecutor hangs forever:

```
from contextvars import ContextVar, copy_context
from concurrent.futures import ProcessPoolExecutor
from multiprocessing import Process

var: ContextVar[int] = ContextVar('var',default=None)

if __name__ == '__main__':
    
    # ***** This hangs forever *****
    with ProcessPoolExecutor(max_workers=1) as pp:
        ctx = copy_context()
        pp.submit(ctx.run, list)

    # ****** This throws 'cannot pickle Context' ***** 
    ctx = copy_context()
    p = Process(target=ctx.run, args=(list,))
    p.start()
    p.join()
```

python version is 3.8.0
running on Mac OSX 10.15.1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39257>
_______________________________________

From report at bugs.python.org  Wed Jan  8 05:45:02 2020
From: report at bugs.python.org (And Clover)
Date: Wed, 08 Jan 2020 10:45:02 +0000
Subject: [issue23434] support encoded filename in Content-Disposition for HTTP
 in cgi.FieldStorage
In-Reply-To: <1423580087.81.0.367611213854.issue23434@psf.upfronthosting.co.za>
Message-ID: <1578480302.35.0.43830644153.issue23434@roundup.psfhosted.org>


And Clover <and at doxdesk.com> added the comment:

> Are you saying there is no (http) RFC compliant way to fix this

Sadly, yes.

And though RFCs aren't always a fair representation of real-world use, RFC 7578 is informative as well as normative: at present nothing produces "filename*=" in multipart/form-data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23434>
_______________________________________

From report at bugs.python.org  Wed Jan  8 05:49:56 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 08 Jan 2020 10:49:56 +0000
Subject: [issue39222] unittest.mock.Mock.parent is broken or undocumented
In-Reply-To: <1578236312.03.0.58171840403.issue39222@roundup.psfhosted.org>
Message-ID: <1578480596.59.0.40750208937.issue39222@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

It's a similar situation to name argument conflict [0] except that it's parent here. You can use configure_mock or attribute setting to do the same thing like below. parent is discussed in the docs to indicate the attributes being children like "a" being the child of parent "m" as you have mentioned. Adding others for thoughts. 

>>> from unittest.mock import Mock
>>> m = Mock()
>>> m.configure_mock(parent=2)
>>> m.parent
2
>>> m.a()
<Mock name='mock.a()' id='4367727104'>

>>> m = Mock()
>>> m.parent = 2
>>> m.parent
2

[0] https://docs.python.org/3/library/unittest.mock.html#mock-names-and-the-name-attribute

----------
nosy: +cjw296, lisroach, mariocj89, michael.foord
versions: +Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39222>
_______________________________________

From report at bugs.python.org  Wed Jan  8 06:06:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 08 Jan 2020 11:06:36 +0000
Subject: [issue39257] contextvars.Context.run hangs forever in
 ProccessPoolExecutor
In-Reply-To: <1578479674.06.0.280894954081.issue39257@roundup.psfhosted.org>
Message-ID: <1578481596.81.0.700032268987.issue39257@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39257>
_______________________________________

From report at bugs.python.org  Wed Jan  8 06:17:19 2020
From: report at bugs.python.org (Tony Hirst)
Date: Wed, 08 Jan 2020 11:17:19 +0000
Subject: [issue39258] json serialiser errors with numpy int64
Message-ID: <1578482239.09.0.866607627274.issue39258@roundup.psfhosted.org>


Change by Tony Hirst <tony.hirst at gmail.com>:


----------
components: Library (Lib)
nosy: Tony Hirst
priority: normal
severity: normal
status: open
title: json serialiser errors with numpy int64
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39258>
_______________________________________

From report at bugs.python.org  Wed Jan  8 06:18:40 2020
From: report at bugs.python.org (Tony Hirst)
Date: Wed, 08 Jan 2020 11:18:40 +0000
Subject: [issue39258] json serialiser errors with numpy int64
Message-ID: <1578482320.02.0.679700849544.issue39258@roundup.psfhosted.org>


New submission from Tony Hirst <tony.hirst at gmail.com>:

````
import json
import numpy as np

json.dumps( {'int64': np.int64(1)})

TypeError: Object of type int64 is not JSON serializable 
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-67-e2b056f3a557> in <module>
----> 1 json.dumps( {'int64': np.int64(1)})

/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/__init__.py in dumps(obj, skipkeys, ensure_ascii, check_circular, allow_nan, cls, indent, separators, default, sort_keys, **kw)
    229         cls is None and indent is None and separators is None and
    230         default is None and not sort_keys and not kw):
--> 231         return _default_encoder.encode(obj)
    232     if cls is None:
    233         cls = JSONEncoder

/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/encoder.py in encode(self, o)
    197         # exceptions aren't as detailed.  The list call should be roughly
    198         # equivalent to the PySequence_Fast that ''.join() would do.
--> 199         chunks = self.iterencode(o, _one_shot=True)
    200         if not isinstance(chunks, (list, tuple)):
    201             chunks = list(chunks)

/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/encoder.py in iterencode(self, o, _one_shot)
    255                 self.key_separator, self.item_separator, self.sort_keys,
    256                 self.skipkeys, _one_shot)
--> 257         return _iterencode(o, 0)
    258 
    259 def _make_iterencode(markers, _default, _encoder, _indent, _floatstr,

/usr/local/Cellar/python/3.7.5/Frameworks/Python.framework/Versions/3.7/lib/python3.7/json/encoder.py in default(self, o)
    177 
    178         """
--> 179         raise TypeError(f'Object of type {o.__class__.__name__} '
    180                         f'is not JSON serializable')
    181 

TypeError: Object of type int64 is not JSON serializable

````

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39258>
_______________________________________

From report at bugs.python.org  Wed Jan  8 06:21:40 2020
From: report at bugs.python.org (Tony Hirst)
Date: Wed, 08 Jan 2020 11:21:40 +0000
Subject: [issue39258] json serialiser errors with numpy int64
In-Reply-To: <1578482320.02.0.679700849544.issue39258@roundup.psfhosted.org>
Message-ID: <1578482500.76.0.0030474184293.issue39258@roundup.psfhosted.org>


Tony Hirst <tony.hirst at gmail.com> added the comment:

Apols - this is probably strictly a numpy issue.

See: https://github.com/numpy/numpy/issues/12481

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39258>
_______________________________________

From report at bugs.python.org  Wed Jan  8 06:38:59 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 08 Jan 2020 11:38:59 +0000
Subject: [issue39255] Windows and Unix run-time differences
In-Reply-To: <1578473056.67.0.190561060643.issue39255@roundup.psfhosted.org>
Message-ID: <1578483539.2.0.340837255663.issue39255@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I am not going to close it as I am unsure if it is by design that 
> Windows and Unix python acts differently.

For compatibility, a script should support the spawn start method. Spawning child processes is the only available start method in Windows, and, as of Python 3.8 (see issue 33725), it's the default start method in macOS. This entails passing picklable objects as arguments or with a multiprocessing.Queue or multiprocessing.Pipe -- instead of relying on global values that get inherited via fork. 

With a pool you can set up globals with an initializer function. Here's an example of the latter that manually selects the spawn start method:

    import multiprocessing as mp

    def pool_init(x_value, y_value):
        global x, y
        x = x_value
        y = y_value

    if __name__ == '__main__':
        mp.set_start_method('spawn')
        pool = mp.Pool(processes=2, initializer=pool_init,
                        initargs=(mp.Value('i', 0), mp.Value('i', 0)))

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39255>
_______________________________________

From report at bugs.python.org  Wed Jan  8 06:51:52 2020
From: report at bugs.python.org (Tony Hirst)
Date: Wed, 08 Jan 2020 11:51:52 +0000
Subject: [issue39258] json serialiser errors with numpy int64
In-Reply-To: <1578482320.02.0.679700849544.issue39258@roundup.psfhosted.org>
Message-ID: <1578484312.95.0.00625824366945.issue39258@roundup.psfhosted.org>


Tony Hirst <tony.hirst at gmail.com> added the comment:

Previously posted issue: https://bugs.python.org/issue22107

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39258>
_______________________________________

From report at bugs.python.org  Wed Jan  8 06:53:11 2020
From: report at bugs.python.org (Tony Hirst)
Date: Wed, 08 Jan 2020 11:53:11 +0000
Subject: [issue39258] json serialiser errors with numpy int64
In-Reply-To: <1578482320.02.0.679700849544.issue39258@roundup.psfhosted.org>
Message-ID: <1578484391.89.0.849544584564.issue39258@roundup.psfhosted.org>


Tony Hirst <tony.hirst at gmail.com> added the comment:

Argh: previous was incorrect associated issue: correct issue: https://bugs.python.org/issue24313

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39258>
_______________________________________

From report at bugs.python.org  Wed Jan  8 07:31:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 08 Jan 2020 12:31:36 +0000
Subject: [issue39258] json serialiser errors with numpy int64
In-Reply-To: <1578482320.02.0.679700849544.issue39258@roundup.psfhosted.org>
Message-ID: <1578486696.85.0.201787140221.issue39258@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Closing it as duplicate.

----------
nosy: +xtreak
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> json fails to serialise numpy.int64

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39258>
_______________________________________

From report at bugs.python.org  Wed Jan  8 07:45:48 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 08 Jan 2020 12:45:48 +0000
Subject: [issue39256] Exception handler set by set_exception_handler is called
 only when I run coroutine by create_task
In-Reply-To: <1578476507.18.0.348977530849.issue39256@roundup.psfhosted.org>
Message-ID: <1578487548.71.0.157499102628.issue39256@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

asyncio exception handler is supposed to catch *unhandled* exceptions only, not all raised ones.

The first two cases from your example propagate raised exceptions to the caller, these exceptions are unwound in a regular manner.
So, no need to call the exception handler.

The third case is different, an exception from a spawned task is not propagated to the parent task implicitly. That's why the exception is *unhandled* and passed to the registered exception handler.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39256>
_______________________________________

From report at bugs.python.org  Wed Jan  8 07:49:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 12:49:00 +0000
Subject: [issue39242] Update news.gmane.org to news.gmane.io
In-Reply-To: <1578382085.09.0.293761800021.issue39242@roundup.psfhosted.org>
Message-ID: <1578487740.64.0.313025841688.issue39242@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Correct: nntplib and test_nntplib should be updated:

Doc/library/nntplib.rst:23:   >>> s = nntplib.NNTP('news.gmane.org')
Doc/library/nntplib.rst:47:   >>> s = nntplib.NNTP('news.gmane.org')
Doc/library/nntplib.rst:76:    >>> with NNTP('news.gmane.org') as n:
Doc/library/nntplib.rst:228:      >>> s = NNTP('news.gmane.org')
Doc/whatsnew/3.3.rst:1565:  >>> with NNTP('news.gmane.org') as n:
Lib/nntplib.py:1110:    parser.add_argument('-s', '--server', default='news.gmane.org',
Lib/test/test_nntplib.py:642:                    "\tXref: news.gmane.org gmane.comp.python.authors:57"
Lib/test/test_nntplib.py:1128:            "xref": "news.gmane.org gmane.comp.python.authors:57"

Do you want to work on a pull request?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39242>
_______________________________________

From report at bugs.python.org  Wed Jan  8 07:50:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 12:50:37 +0000
Subject: [issue39241] Popen of python3.6 hangs on os.read(errpipe_read, 50000)
In-Reply-To: <1578360908.03.0.624419556785.issue39241@roundup.psfhosted.org>
Message-ID: <1578487837.44.0.732851655649.issue39241@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

os.pipe() creates non-inheritable file descriptors by default, see PEP 446:

$ python3.6
Python 3.6.9 (default, Jul 26 2019, 00:00:00) 
>>> import os
>>> a,b=os.pipe()
>>> os.get_inheritable(a)
False
>>> os.get_inheritable(b)
False

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39241>
_______________________________________

From report at bugs.python.org  Wed Jan  8 07:53:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 12:53:20 +0000
Subject: [issue39237] Redundant call to round in delta_new
In-Reply-To: <1578342169.21.0.342179864502.issue39237@roundup.psfhosted.org>
Message-ID: <1578488000.16.0.397640132953.issue39237@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Alex Henrie, I merged your PR. I don't think that it's worth it to backport such cleanup change to stable branches.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39237>
_______________________________________

From report at bugs.python.org  Wed Jan  8 07:52:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 12:52:48 +0000
Subject: [issue39237] Redundant call to round in delta_new
In-Reply-To: <1578342169.21.0.342179864502.issue39237@roundup.psfhosted.org>
Message-ID: <1578487968.47.0.312419690771.issue39237@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 998c54948a29cf5bd8bfa49f973f1ce5855004a0 by Victor Stinner (Alex Henrie) in branch 'master':
bpo-39237, datetime: Remove redundant call to round from delta_new (GH-17877)
https://github.com/python/cpython/commit/998c54948a29cf5bd8bfa49f973f1ce5855004a0


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39237>
_______________________________________

From report at bugs.python.org  Wed Jan  8 07:57:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 12:57:54 +0000
Subject: [issue39248] test_distutils fails on PPC64 Fedora 3.x:
 /tmp/subprocess.py
In-Reply-To: <1578420731.23.0.752143109381.issue39248@roundup.psfhosted.org>
Message-ID: <1578488274.78.0.0043670606596.issue39248@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: test_distutils fails on PPC64 Fedora 3.x -> test_distutils fails on PPC64 Fedora 3.x: /tmp/subprocess.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39248>
_______________________________________

From report at bugs.python.org  Wed Jan  8 07:58:32 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 08 Jan 2020 12:58:32 +0000
Subject: [issue39231] Mistaken notion in tutorial
In-Reply-To: <1578334311.83.0.989380005846.issue39231@roundup.psfhosted.org>
Message-ID: <1578488312.83.0.975894245632.issue39231@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Robert]

> It is not a "positional argument" but an "optional argument".

I don't think I understand. Here the phrase "positional argument" in the docs is, I assume, referring to the parameter "ham: str" in the parameter list. So it's not optional; it's a required, positional-or-keyword parameter.

I don't know whether the text of this section should be being tightened up with respect to the distinction between (formal) parameters and actual arguments, though. There's a tradeoff between readability and accessibility on the one hand, and technical accuracy on the other.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39231>
_______________________________________

From report at bugs.python.org  Wed Jan  8 08:00:18 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jan 2020 13:00:18 +0000
Subject: [issue39233] glossary entry for parameter out-of-date for
 positional-only parameters
In-Reply-To: <1578336890.4.0.142758348692.issue39233@roundup.psfhosted.org>
Message-ID: <1578488418.35.0.0752931106462.issue39233@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9a669d58e8cb586fba38c84d5b631cd8a95d0c0c by Miss Islington (bot) (Pablo Galindo) in branch 'master':
bpo-39233: Update positional-only section in the glossary (GH-17874)
https://github.com/python/cpython/commit/9a669d58e8cb586fba38c84d5b631cd8a95d0c0c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39233>
_______________________________________

From report at bugs.python.org  Wed Jan  8 08:00:41 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jan 2020 13:00:41 +0000
Subject: [issue39233] glossary entry for parameter out-of-date for
 positional-only parameters
In-Reply-To: <1578336890.4.0.142758348692.issue39233@roundup.psfhosted.org>
Message-ID: <1578488441.72.0.20958201642.issue39233@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17314
pull_request: https://github.com/python/cpython/pull/17902

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39233>
_______________________________________

From report at bugs.python.org  Wed Jan  8 08:21:45 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 08 Jan 2020 13:21:45 +0000
Subject: [issue39242] Update news.gmane.org to news.gmane.io
In-Reply-To: <1578382085.09.0.293761800021.issue39242@roundup.psfhosted.org>
Message-ID: <1578489705.67.0.650088804729.issue39242@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@vstinner

Oh! sure, I will submit the PR right a way :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39242>
_______________________________________

From report at bugs.python.org  Wed Jan  8 08:32:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 13:32:02 +0000
Subject: [issue6531] atexit_callfuncs() crashing within Py_Finalize() when
 using multiple interpreters.
In-Reply-To: <1248175169.79.0.15962102552.issue6531@psf.upfronthosting.co.za>
Message-ID: <1578490322.67.0.931869176531.issue6531@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6531>
_______________________________________

From report at bugs.python.org  Wed Jan  8 08:36:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 13:36:19 +0000
Subject: [issue24554] GC should happen when a subinterpreter is destroyed
In-Reply-To: <1435884077.54.0.517018915499.issue24554@psf.upfronthosting.co.za>
Message-ID: <1578490579.46.0.88065475629.issue24554@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Py_EndInterpreter() now calls gc.collect() at least twice: at the end of _PyImport_Cleanup() and in finalize_interp_clear(). I now consider the issue as fixed and so I close it.

The issue that I described in my previous comment can be enhanced/fixed later.

----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24554>
_______________________________________

From report at bugs.python.org  Wed Jan  8 08:51:35 2020
From: report at bugs.python.org (Alan Robertson)
Date: Wed, 08 Jan 2020 13:51:35 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1578491495.22.0.138187530171.issue38780@roundup.psfhosted.org>


Alan Robertson <alanr at unix.sh> added the comment:

There are a variety of different reasons this can fail, not just on MacOS. You could give it a bad IP address of a server, etc. [That was my particular case].

The constructor should create an attribute 'socket' and initialize it to None early on. Then, the close function in logging/handlers.py should check for None. Or alternatively, it shouldn't register the object with atexit until it's been constructed "well-enough".

----------
nosy: +alanr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Wed Jan  8 09:05:06 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 08 Jan 2020 14:05:06 +0000
Subject: [issue34033] distutils is not reproducible
In-Reply-To: <1530632785.81.0.56676864532.issue34033@psf.upfronthosting.co.za>
Message-ID: <1578492306.81.0.929647322653.issue34033@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

> There is also one aspect where i586 builds end up with different .pyc files than x86_64 builds. And then we randomly chose one of them for our "noarch" python module packages and hope they work everywhere (including on arm and s390 architectures).

They are functionally identical, despite not being bit-by-bit identical.
If they do not work everywhere, it's a very serious bug.

> So is someone working towards a concept that makes it is possible to create the same .pyc files anywhere?

No, it's a known issue no one is working on.

> Can I help something there?

Maybe?
The two main culprits are in the marshal serialization algorithm:  https://github.com/python/cpython/blob/master/Python/marshal.c
Specifically:
- a heuristic depends on refcount (i.e. state of objects in the entire interpreter, rather than just relationships between serialized objects): https://github.com/python/cpython/blob/33b671e72450bf4b5a946ce0dde6b7fe21150108/Python/marshal.c#L304
- (frozen)sets are serialized in iteration order, which is unpredictable (and determinig a predictable order is not trivial): https://github.com/python/cpython/blob/33b671e72450bf4b5a946ce0dde6b7fe21150108/Python/marshal.c#L498

A solution will probably come with an unacceptable performance hit -- it's good to keep generating the .pyc files fast. Two options to overcome that come to mind:
- make reproducibility optional (which would make the testing more cumbersome)
- make an add-on tool to re-serialize an existing .pyc.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34033>
_______________________________________

From report at bugs.python.org  Wed Jan  8 09:29:27 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 08 Jan 2020 14:29:27 +0000
Subject: [issue39242] Update news.gmane.org to news.gmane.io
In-Reply-To: <1578382085.09.0.293761800021.issue39242@roundup.psfhosted.org>
Message-ID: <1578493767.93.0.983541930222.issue39242@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17315
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17903

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39242>
_______________________________________

From report at bugs.python.org  Wed Jan  8 09:55:46 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 08 Jan 2020 14:55:46 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
Message-ID: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

Since poplib.POP3/POP3_SSL's implementation depends on socket.makefile, the client should reject if the timeout is zero.
Because socket.makefile said that 'The socket must be in blocking mode' and if we set timeout to zero, the client does not operate as normal.

----------
components: Library (Lib)
messages: 359596
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: poplib.POP3/POP3_SSL should reject timeout = 0
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Wed Jan  8 10:29:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 15:29:49 +0000
Subject: [issue39242] Update news.gmane.org to news.gmane.io
In-Reply-To: <1578382085.09.0.293761800021.issue39242@roundup.psfhosted.org>
Message-ID: <1578497389.35.0.521141573425.issue39242@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 2e6a8efa837410327b593dc83c57492253b1201e by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-39242: Updated the Gmane domain into news.gmane.io (GH-17903)
https://github.com/python/cpython/commit/2e6a8efa837410327b593dc83c57492253b1201e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39242>
_______________________________________

From report at bugs.python.org  Wed Jan  8 10:29:55 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jan 2020 15:29:55 +0000
Subject: [issue39242] Update news.gmane.org to news.gmane.io
In-Reply-To: <1578382085.09.0.293761800021.issue39242@roundup.psfhosted.org>
Message-ID: <1578497395.36.0.49327959128.issue39242@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17316
pull_request: https://github.com/python/cpython/pull/17904

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39242>
_______________________________________

From report at bugs.python.org  Wed Jan  8 10:30:07 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jan 2020 15:30:07 +0000
Subject: [issue39242] Update news.gmane.org to news.gmane.io
In-Reply-To: <1578382085.09.0.293761800021.issue39242@roundup.psfhosted.org>
Message-ID: <1578497407.72.0.374506734209.issue39242@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17317
pull_request: https://github.com/python/cpython/pull/17905

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39242>
_______________________________________

From report at bugs.python.org  Wed Jan  8 10:31:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 15:31:39 +0000
Subject: [issue39242] Update news.gmane.org to news.gmane.io
In-Reply-To: <1578382085.09.0.293761800021.issue39242@roundup.psfhosted.org>
Message-ID: <1578497499.9.0.489213269251.issue39242@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Dong-hee Na for the update. The fix landed in master, backports to 3.7 and 3.8 will automatically follow once the CI test will pas.

----------
components: +Library (Lib), Tests
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39242>
_______________________________________

From report at bugs.python.org  Wed Jan  8 10:47:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 15:47:29 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578498449.51.0.57828400437.issue39259@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I agree, I was the one who suggest to reject timeout=0 when you added the parameter to imaplib :-)

Do you want to work on a PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Wed Jan  8 10:47:35 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jan 2020 15:47:35 +0000
Subject: [issue39242] Update news.gmane.org to news.gmane.io
In-Reply-To: <1578382085.09.0.293761800021.issue39242@roundup.psfhosted.org>
Message-ID: <1578498455.69.0.88829733345.issue39242@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 00ac28ac4d06a311fc2386ef921b2603735ffae6 by Miss Islington (bot) in branch '3.7':
bpo-39242: Updated the Gmane domain into news.gmane.io (GH-17903)
https://github.com/python/cpython/commit/00ac28ac4d06a311fc2386ef921b2603735ffae6


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39242>
_______________________________________

From report at bugs.python.org  Wed Jan  8 10:47:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 15:47:40 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578498460.35.0.907167773804.issue39259@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: poplib.POP3/POP3_SSL should reject timeout = 0 -> poplib.POP3/POP3_SSL should reject timeout = 0 (non-blocking mode)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Wed Jan  8 10:48:37 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 08 Jan 2020 15:48:37 +0000
Subject: [issue39242] Update news.gmane.org to news.gmane.io
In-Reply-To: <1578382085.09.0.293761800021.issue39242@roundup.psfhosted.org>
Message-ID: <1578498517.21.0.0340940864079.issue39242@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b24e4fac03409c4f845758d7ed884c5a99368493 by Miss Islington (bot) in branch '3.8':
bpo-39242: Updated the Gmane domain into news.gmane.io (GH-17903)
https://github.com/python/cpython/commit/b24e4fac03409c4f845758d7ed884c5a99368493


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39242>
_______________________________________

From report at bugs.python.org  Wed Jan  8 10:53:12 2020
From: report at bugs.python.org (Thomas Passin)
Date: Wed, 08 Jan 2020 15:53:12 +0000
Subject: [issue39260] find_executable() Fails To Find Many Executables on
 Windows
Message-ID: <1578498792.76.0.781232335261.issue39260@roundup.psfhosted.org>


New submission from Thomas Passin <pub1 at tompassin.net>:

On Windows, find_executable() in distutils.spawn may fail to find executables that it ought to.  This is because the PATH environmental variable no longer includes %ProgramFiles% and %ProgramFiles(x86)%.  At least, that is the case on my brand new Windows 10 Computer running Windows 10 Pro.  In the past, I'm fairly sure these directories were always included on the PATH.

Some programs add their install directory to the Windows PATH, but many don't.  For example, on my new computer, Pandoc added itself to the PATH but EditPlus and Notepad++ did not.  So

    >>> find_executable('pandoc')
    'C:\\Program Files\\Pandoc\\pandoc.exe'
but
    >>> find_executable('editplus')   # no result
    >>> find_executable('notepad++')  # no result

I suggest that in Windows, find_executable() should check for and add the %ProgramFiles% and %ProgramFiles(x86)% directories to the system PATH before executing its search.

----------
components: Distutils
messages: 359602
nosy: dstufft, eric.araujo, tbpassin
priority: normal
severity: normal
status: open
title: find_executable() Fails To Find Many Executables on Windows
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39260>
_______________________________________

From report at bugs.python.org  Wed Jan  8 10:55:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 15:55:40 +0000
Subject: [issue39260] find_executable() Fails To Find Many Executables on
 Windows
In-Reply-To: <1578498792.76.0.781232335261.issue39260@roundup.psfhosted.org>
Message-ID: <1578498940.76.0.945133129423.issue39260@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

find_executable() rely on the PATH environment variable:

def find_executable(executable, path=None):
    """Tries to find 'executable' in the directories listed in 'path'.

    A string listing directories separated by 'os.pathsep'; defaults to
    os.environ['PATH'].  Returns the complete filename or None if not found.
    """

You may add manually %ProgramFiles% and %ProgramFiles(x86)% to your PATH if they aren't already there.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39260>
_______________________________________

From report at bugs.python.org  Wed Jan  8 10:55:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 15:55:48 +0000
Subject: [issue39260] distutils.spawn: find_executable() Fails To Find Many
 Executables on Windows
In-Reply-To: <1578498792.76.0.781232335261.issue39260@roundup.psfhosted.org>
Message-ID: <1578498948.29.0.203175043979.issue39260@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: find_executable() Fails To Find Many Executables on Windows -> distutils.spawn: find_executable() Fails To Find Many Executables on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39260>
_______________________________________

From report at bugs.python.org  Wed Jan  8 11:07:25 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 08 Jan 2020 16:07:25 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578499645.93.0.820911364087.issue39259@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Sure, I will submit the PR by tomorrow :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Wed Jan  8 11:18:12 2020
From: report at bugs.python.org (Batuhan)
Date: Wed, 08 Jan 2020 16:18:12 +0000
Subject: [issue28002] Some f-strings do not round trip through
 Tools/parser/test_unparse.py
In-Reply-To: <1473268698.62.0.800338957351.issue28002@psf.upfronthosting.co.za>
Message-ID: <1578500292.08.0.736833766802.issue28002@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28002>
_______________________________________

From report at bugs.python.org  Wed Jan  8 11:18:44 2020
From: report at bugs.python.org (Batuhan)
Date: Wed, 08 Jan 2020 16:18:44 +0000
Subject: [issue28002] ast.unparse can't roundtrip some f-strings
In-Reply-To: <1473268698.62.0.800338957351.issue28002@psf.upfronthosting.co.za>
Message-ID: <1578500324.06.0.949229518697.issue28002@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
components: +Library (Lib) -Demos and Tools
title: Some f-strings do not round trip through Tools/parser/test_unparse.py -> ast.unparse can't roundtrip some f-strings
versions: +Python 3.9 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28002>
_______________________________________

From report at bugs.python.org  Wed Jan  8 11:27:46 2020
From: report at bugs.python.org (Thomas Passin)
Date: Wed, 08 Jan 2020 16:27:46 +0000
Subject: [issue39260] distutils.spawn: find_executable() Fails To Find Many
 Executables on Windows
In-Reply-To: <1578498792.76.0.781232335261.issue39260@roundup.psfhosted.org>
Message-ID: <1578500866.04.0.330474255287.issue39260@roundup.psfhosted.org>


Thomas Passin <pub1 at tompassin.net> added the comment:

Well, yes, I realize that I could add the directories.  But random users of find_executible may not realize that.

Actually, it's probably a bit more complex than just adding the top-level directories %ProgramFiles% and %ProgramFiles(x86)%, because  find_executable probably doesn't do a recursive search.  In that the best tactic would be to look in those top-level directories for a directory with the same name as the executable.  If one is found, then look in it for the actual file.

For example, on my computer, inkscape.exe is at %ProgramFiles%\Inkscape
inkscape.exe, and that pattern is very common.

This tactic would find many of the otherwise unfound executables, and still execute quickly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39260>
_______________________________________

From report at bugs.python.org  Wed Jan  8 11:33:20 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Jan 2020 16:33:20 +0000
Subject: [issue39253] Running the test suite with --junit-xml and -R
 incorrectly reports refleaks
In-Reply-To: <1578441293.88.0.429793229703.issue39253@roundup.psfhosted.org>
Message-ID: <1578501200.45.0.409507552248.issue39253@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

We can stop using --junit-xml if we want. GitHub Actions doesn't support displaying test results anyway, so once Azure Pipelines is switched off we'll just be reading the console all the time anyway (unless Buildbot has a way of rendering test results that I haven't noticed?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39253>
_______________________________________

From report at bugs.python.org  Wed Jan  8 11:35:27 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Jan 2020 16:35:27 +0000
Subject: [issue39243] CDLL __init__ no longer supports name being passed as
 None when the handle is not None
In-Reply-To: <1578394425.89.0.0381750651285.issue39243@roundup.psfhosted.org>
Message-ID: <1578501327.49.0.697605813122.issue39243@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I think it would be cleaner to split out the platform-specific work into a separate _load_library method

SGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39243>
_______________________________________

From report at bugs.python.org  Wed Jan  8 11:35:53 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Jan 2020 16:35:53 +0000
Subject: [issue39253] Running the test suite with --junit-xml and -R
 incorrectly reports refleaks
In-Reply-To: <1578441293.88.0.429793229703.issue39253@roundup.psfhosted.org>
Message-ID: <1578501353.49.0.175653845865.issue39253@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

My guess would be that the reference tracking needs some kind of awareness for logging results. The results are collected as regular Python objects and formatted later, as we need to calculate totals before writing the XML file.

I guess keeping those objects around looks like a leak?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39253>
_______________________________________

From report at bugs.python.org  Wed Jan  8 11:37:42 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Jan 2020 16:37:42 +0000
Subject: [issue39255] Windows and Unix run-time differences
In-Reply-To: <1578473056.67.0.190561060643.issue39255@roundup.psfhosted.org>
Message-ID: <1578501462.02.0.846438977818.issue39255@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Agreed it's not a bug.

The best we could do is display a warning that fork is not portable (won't work on macOS anymore either, IIRC) and you should at least verify that spawn behaves the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39255>
_______________________________________

From report at bugs.python.org  Wed Jan  8 11:43:53 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 08 Jan 2020 16:43:53 +0000
Subject: [issue39253] Running the test suite with --junit-xml and -R
 incorrectly reports refleaks
In-Reply-To: <1578441293.88.0.429793229703.issue39253@roundup.psfhosted.org>
Message-ID: <1578501833.45.0.621832371161.issue39253@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> We can stop using --junit-xml if we want. GitHub Actions doesn't support displaying test results anyway, so once Azure Pipelines is switched off we'll just be reading the console all the time anyway (unless Buildbot has a way of rendering test results that I haven't noticed?)


We are using --junit-xml on the buildbots to analyze failures and in the future we can use it to better display the summary, as is more reliable than parsing the longs.

> I guess keeping those objects around looks like a leak?

Yeah, because it seems that we collect those objects in the innermost runner, while the refleak runner runs the whole "test suite" (the test file, like test_list.py) as one unit.

To be honest, the easiest fix here maybe is just deactivating the --junit and make a warning as in bpo-27103

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39253>
_______________________________________

From report at bugs.python.org  Wed Jan  8 11:44:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 08 Jan 2020 16:44:20 +0000
Subject: [issue39253] Running the test suite with --junit-xml and -R
 incorrectly reports refleaks
In-Reply-To: <1578441293.88.0.429793229703.issue39253@roundup.psfhosted.org>
Message-ID: <1578501860.16.0.788178438676.issue39253@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> deactivating the --junit

I mean deactivating the --junit *if* is used together with -R

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39253>
_______________________________________

From report at bugs.python.org  Wed Jan  8 11:57:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 16:57:58 +0000
Subject: [issue39253] Running the test suite with --junit-xml and -R
 incorrectly reports refleaks
In-Reply-To: <1578441293.88.0.429793229703.issue39253@roundup.psfhosted.org>
Message-ID: <1578502678.75.0.440469985414.issue39253@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

FYI test_io is skipped in Python 2.7 when using -R, because test_io is not reliable. Extract of Lib/test/test_io.py:

    if huntrleaks:
        # FIXME: bpo-31731: test_io hangs with --huntrleaks
        print("Warning: bpo-31731: test_io hangs with --huntrleaks: "
              "exclude the test")
        nottests.add('test_io')

I'm not shocked by disabling JUnit feature when using -R. But I suggest to raise an error and tune the buildbot configuration to not use it, rather than silently ignore the option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39253>
_______________________________________

From report at bugs.python.org  Wed Jan  8 12:13:39 2020
From: report at bugs.python.org (Paul Moore)
Date: Wed, 08 Jan 2020 17:13:39 +0000
Subject: [issue39255] Windows and Unix run-time differences
In-Reply-To: <1578473056.67.0.190561060643.issue39255@roundup.psfhosted.org>
Message-ID: <1578503619.96.0.777167799638.issue39255@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Agreed it's not a bug, but I will say it took me a while to work out *why* it's not a bug (namely, that even though the OP is using shared memory values, the code relies on fork semantics to share the two Value objects that *reference* the shared memory).

It would be worth adding a note to the documentation on shared memory values at https://docs.python.org/3.8/library/multiprocessing.html#sharing-state-between-processes to make it clearer that it's the user's responsibility to make sure the Value object is passed to every subprocess that wants to interact with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39255>
_______________________________________

From report at bugs.python.org  Wed Jan  8 12:25:22 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 08 Jan 2020 17:25:22 +0000
Subject: [issue39260] distutils.spawn: find_executable() Fails To Find Many
 Executables on Windows
In-Reply-To: <1578498792.76.0.781232335261.issue39260@roundup.psfhosted.org>
Message-ID: <1578504322.05.0.393539756036.issue39260@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> In that the best tactic would be to look in those top-level 
> directories for a directory with the same name as the executable.

It may be a common pattern, but such a guess is not reliable. The needed executable may be in an unrelated directory at an arbitrary depth in the tree. 

There are reliable ways to find an executable in Windows other than searching PATH -- assuming the application wants to be found in a reliable way. For example, we can use winreg to search the subkey names of "[HKCU|HKLM]\Software\Microsoft\Windows\CurrentVersion\App Paths" for the given executable name (e.g. "notepad++.exe"). The default value of each subkey is the fully-qualified path of the executable.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39260>
_______________________________________

From report at bugs.python.org  Wed Jan  8 12:31:56 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 08 Jan 2020 17:31:56 +0000
Subject: [issue39253] Running the test suite with --junit-xml and -R
 incorrectly reports refleaks
In-Reply-To: <1578441293.88.0.429793229703.issue39253@roundup.psfhosted.org>
Message-ID: <1578504716.81.0.775907667579.issue39253@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>  But I suggest to raise an error and tune the buildbot configuration to not use it, rather than silently ignore the option.

I already configured the buildbots to not use --junit when running with =R

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39253>
_______________________________________

From report at bugs.python.org  Wed Jan  8 12:45:59 2020
From: report at bugs.python.org (Alex Henrie)
Date: Wed, 08 Jan 2020 17:45:59 +0000
Subject: [issue39237] Redundant call to round in delta_new
In-Reply-To: <1578342169.21.0.342179864502.issue39237@roundup.psfhosted.org>
Message-ID: <1578505559.23.0.0827632921514.issue39237@roundup.psfhosted.org>


Alex Henrie <alexhenrie24 at gmail.com> added the comment:

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39237>
_______________________________________

From report at bugs.python.org  Wed Jan  8 12:50:54 2020
From: report at bugs.python.org (Thomas Passin)
Date: Wed, 08 Jan 2020 17:50:54 +0000
Subject: [issue39260] distutils.spawn: find_executable() Fails To Find Many
 Executables on Windows
In-Reply-To: <1578498792.76.0.781232335261.issue39260@roundup.psfhosted.org>
Message-ID: <1578505854.03.0.346036289439.issue39260@roundup.psfhosted.org>


Thomas Passin <pub1 at tompassin.net> added the comment:

That's so, and with a bit more complexity might be worth doing.  At least, it would be good to have *some* means to find more the the executable files one would expect to find.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39260>
_______________________________________

From report at bugs.python.org  Wed Jan  8 12:53:04 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 08 Jan 2020 17:53:04 +0000
Subject: [issue39255] Windows and Unix run-time differences
In-Reply-To: <1578473056.67.0.190561060643.issue39255@roundup.psfhosted.org>
Message-ID: <1578505984.33.0.961508387754.issue39255@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Agreed it's not a bug, but I will say it took me a while to work out 
> *why* it's not a bug (namely, that even though the OP is using shared 
> memory values, the code relies on fork semantics to share the two 
> Value objects that *reference* the shared memory).

The programming guidelines cover this under "explicitly pass resources to child processes" and "the spawn and forkserver start methods". Even for scripts that will only ever use the fork start method, it explains why inheriting globals may be a problem due to garbage collection in the parent. What can be done to make the advice there more visible and easily understood?

I'd guess that, even though it took you a while to spot the problem, you wouldn't make the same mistake if writing this from scratch -- assuming you've read and understood the programming guidelines. There's nothing about an arbitrary Value instance that would allow a spawned child process to map it to the shared memory of a Value in the parent process. That information has to be pickled and sent to the child.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39255>
_______________________________________

From report at bugs.python.org  Wed Jan  8 13:11:55 2020
From: report at bugs.python.org (Alex Henrie)
Date: Wed, 08 Jan 2020 18:11:55 +0000
Subject: [issue39261] Dead assignment in pyinit_config
Message-ID: <1578507115.64.0.589303193818.issue39261@roundup.psfhosted.org>


New submission from Alex Henrie <alexhenrie24 at gmail.com>:

The function pyinit_config currently contains the following line:

    config = &tstate->interp->config;

However, the config variable is not used after that point.

Victor Stinner has confirmed that this assignment is unnecessary: https://github.com/python/cpython/pull/16267/files#r364216184

----------
messages: 359619
nosy: alex.henrie
priority: normal
severity: normal
status: open
title: Dead assignment in pyinit_config

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39261>
_______________________________________

From report at bugs.python.org  Wed Jan  8 13:13:25 2020
From: report at bugs.python.org (Alex Henrie)
Date: Wed, 08 Jan 2020 18:13:25 +0000
Subject: [issue39261] Dead assignment in pyinit_config
In-Reply-To: <1578507115.64.0.589303193818.issue39261@roundup.psfhosted.org>
Message-ID: <1578507205.52.0.280453377593.issue39261@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
keywords: +patch
pull_requests: +17318
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17907

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39261>
_______________________________________

From report at bugs.python.org  Wed Jan  8 13:19:49 2020
From: report at bugs.python.org (Alex Henrie)
Date: Wed, 08 Jan 2020 18:19:49 +0000
Subject: [issue39261] Dead assignment in pyinit_config
In-Reply-To: <1578507115.64.0.589303193818.issue39261@roundup.psfhosted.org>
Message-ID: <1578507589.65.0.242533038183.issue39261@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39261>
_______________________________________

From report at bugs.python.org  Wed Jan  8 13:21:09 2020
From: report at bugs.python.org (Alex Henrie)
Date: Wed, 08 Jan 2020 18:21:09 +0000
Subject: [issue39261] Dead assignment in pyinit_config
In-Reply-To: <1578507115.64.0.589303193818.issue39261@roundup.psfhosted.org>
Message-ID: <1578507669.03.0.801848961232.issue39261@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39261>
_______________________________________

From report at bugs.python.org  Wed Jan  8 13:22:29 2020
From: report at bugs.python.org (Alex Henrie)
Date: Wed, 08 Jan 2020 18:22:29 +0000
Subject: [issue39262] Unused error message in _sharedexception_bind
Message-ID: <1578507749.56.0.495941888024.issue39262@roundup.psfhosted.org>


New submission from Alex Henrie <alexhenrie24 at gmail.com>:

The function _sharedexception_bind currently has the following bit of code in two places:

    if (PyErr_ExceptionMatches(PyExc_MemoryError)) {
        failure = "out of memory copying exception type name";
    }
    failure = "unable to encode and copy exception type name";

The "out of memory" message will never appear because it is immediately overwritten with a more generic message.

----------
messages: 359620
nosy: alex.henrie
priority: normal
severity: normal
status: open
title: Unused error message in _sharedexception_bind
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39262>
_______________________________________

From report at bugs.python.org  Wed Jan  8 13:24:50 2020
From: report at bugs.python.org (Alex Henrie)
Date: Wed, 08 Jan 2020 18:24:50 +0000
Subject: [issue39262] Unused error message in _sharedexception_bind
In-Reply-To: <1578507749.56.0.495941888024.issue39262@roundup.psfhosted.org>
Message-ID: <1578507890.3.0.170062897269.issue39262@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
keywords: +patch
pull_requests: +17319
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17908

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39262>
_______________________________________

From report at bugs.python.org  Wed Jan  8 13:28:23 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Jan 2020 18:28:23 +0000
Subject: [issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily
In-Reply-To: <1542822100.42.0.788709270274.issue35292@psf.upfronthosting.co.za>
Message-ID: <1578508103.18.0.482311907101.issue35292@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 5907e61a8d4da6d0f11bf1062d6d17484560a15e by Steve Dower (An Long) in branch 'master':
bpo-35292: Avoid calling mimetypes.init when http.server is imported (GH-17822)
https://github.com/python/cpython/commit/5907e61a8d4da6d0f11bf1062d6d17484560a15e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35292>
_______________________________________

From report at bugs.python.org  Wed Jan  8 13:31:52 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Jan 2020 18:31:52 +0000
Subject: [issue35292] Make SimpleHTTPRequestHandler load mimetypes lazily
In-Reply-To: <1542822100.42.0.788709270274.issue35292@psf.upfronthosting.co.za>
Message-ID: <1578508312.59.0.789029782635.issue35292@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks for the patch!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35292>
_______________________________________

From report at bugs.python.org  Wed Jan  8 13:55:26 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 08 Jan 2020 18:55:26 +0000
Subject: [issue38623] Python documentation should mention how to find
 site-packages
In-Reply-To: <1572302365.38.0.0160311403424.issue38623@roundup.psfhosted.org>
Message-ID: <1578509726.37.0.0911774547782.issue38623@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I think "Python learners deserve to know about "site-packages" and (optionally) "dist-packages" " is a bit strong of a statement. I don't think the tutorial covers how to install third-party package which is what goes into site-packages, so I don't know what benefit they will garner from having that covered in the tutorial to teach the basics of Python. In an intermediate tutorial I can totally understand the explanation along with using e.g. pip, but for a tutorial like this I still think it's unnecessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38623>
_______________________________________

From report at bugs.python.org  Wed Jan  8 13:57:12 2020
From: report at bugs.python.org (Rafael Fontenelle)
Date: Wed, 08 Jan 2020 18:57:12 +0000
Subject: [issue39229] library/functions.rst causes translated builds to fail
In-Reply-To: <1578289110.04.0.11997957012.issue39229@roundup.psfhosted.org>
Message-ID: <1578509832.13.0.827857989704.issue39229@roundup.psfhosted.org>


Rafael Fontenelle <rffontenelle at gmail.com> added the comment:

Hey Julien! I already fixed once, now I fixed them again, but the message persists:


make[1]: Entering directory '/home/rffontenelle/repos/python-docs-pt-br/venv/workdirs/cpython/Doc'
mkdir -p build
Building NEWS from Misc/NEWS.d with blurb
PATH=/home/rffontenelle/repos/python-docs-pt-br/venv/workdirs/cpython/Doc/venv/bin:$PATH sphinx-build -b html -d build/doctrees  -q --keep-going -jauto   \
	-D locale_dirs=/home/rffontenelle/repos/python-docs-pt-br/venv/workdirs/locale        \
	-D language=pt_BR             \
	-D gettext_compact=0                \
	-D latex_engine=xelatex             \
	-D latex_elements.inputenc=         \
	-D latex_elements.fontenc= -W . build/html 
/home/rffontenelle/repos/python-docs-pt-br/venv/workdirs/cpython/Doc/library/functions.rst:: WARNING: inconsistent term references in translated message. original: [], translated: [':ref:`evento de auditoria <auditing>`']
make[1]: *** [Makefile:51: build] Error 1
make[1]: Leaving directory '/home/rffontenelle/repos/python-docs-pt-br/venv/workdirs/cpython/Doc'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39229>
_______________________________________

From report at bugs.python.org  Wed Jan  8 14:00:16 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 08 Jan 2020 19:00:16 +0000
Subject: [issue39129] Incorrect import of TimeoutError while creating happy
 eyeballs connection
In-Reply-To: <1577171053.02.0.187675761973.issue39129@roundup.psfhosted.org>
Message-ID: <1578510016.28.0.720410137147.issue39129@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sorry, I never got around writing a proper test for this so I am moving it to test needed if someone wants to volunteer for it. trio has some test cases for their happy eyeball implementation if it helps : https://github.com/python-trio/trio/blob/c5497c5ac4f6c457e3390c69cb8b5b62eca41979/trio/tests/test_highlevel_open_tcp_stream.py#L326

----------
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39129>
_______________________________________

From report at bugs.python.org  Wed Jan  8 14:24:28 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Jan 2020 19:24:28 +0000
Subject: [issue39251] outdated windows store links in WindowsApps folder
In-Reply-To: <1578431622.31.0.461218812938.issue39251@roundup.psfhosted.org>
Message-ID: <1578511468.01.0.276102735819.issue39251@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

For reference, I'm going to wait for protobuf, simplejson and Tornado to provide Python 3.8 wheels before switching the default version. Ideally I'd like markupsafe to have wheels as well, but they have a fallback so it's okay.

Everything else in the top 100 according to https://hugovk.github.io/top-pypi-packages/ is either pure or has Windows 3.8 wheels already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39251>
_______________________________________

From report at bugs.python.org  Wed Jan  8 14:36:07 2020
From: report at bugs.python.org (Jameson Nash)
Date: Wed, 08 Jan 2020 19:36:07 +0000
Subject: [issue39263] Windows Installer can't select TargetDir in UI?
Message-ID: <1578512167.47.0.555235356189.issue39263@roundup.psfhosted.org>


New submission from Jameson Nash <vtjnash at gmail.com>:

When running the installer on Windows, I wanted to put Python in an easily accessible path (C:\Python38 in my case), however, the GUI didn't seem to provide any way to change the path (from AppData). And additionally, the "install for all users" checkbox seemed to be broken (didn't respond to mouse events and remained checked). Running the installer with the argument TargetDir=C:\Python38 worked, but I wouldn't have expected to need to hack my way to just picking the install directory.

----------
components: Installation, Windows
messages: 359627
nosy: Jameson Nash, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Installer can't select TargetDir in UI?
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39263>
_______________________________________

From report at bugs.python.org  Wed Jan  8 14:44:28 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Jan 2020 19:44:28 +0000
Subject: [issue39263] Windows Installer can't select TargetDir in UI?
In-Reply-To: <1578512167.47.0.555235356189.issue39263@roundup.psfhosted.org>
Message-ID: <1578512668.57.0.153445041758.issue39263@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

You could have chosen the "Customize installation" button (see the screenshot at https://docs.python.org/3.8/using/windows.html#installation-steps). The description says "Choose location and features".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39263>
_______________________________________

From report at bugs.python.org  Wed Jan  8 14:46:05 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 08 Jan 2020 19:46:05 +0000
Subject: [issue39263] Windows Installer can't select TargetDir in UI?
In-Reply-To: <1578512167.47.0.555235356189.issue39263@roundup.psfhosted.org>
Message-ID: <1578512765.74.0.004088965402.issue39263@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

You may have already had a previous install that was being upgraded. In that case, you should uninstall the old one and then install it to a new location (or else you may end up with some subtle corruption).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39263>
_______________________________________

From report at bugs.python.org  Wed Jan  8 14:53:42 2020
From: report at bugs.python.org (Paul Moore)
Date: Wed, 08 Jan 2020 19:53:42 +0000
Subject: [issue39255] Windows and Unix run-time differences
In-Reply-To: <1578473056.67.0.190561060643.issue39255@roundup.psfhosted.org>
Message-ID: <1578513222.27.0.424708782807.issue39255@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

For me, I headed straight for "Sharing state between processes" and the "Shared memory" object. That's probably because I was reviewing someone else's code, rather than writing my own, but nevertheless when coding I do tend to dive straight for the section that describes what I want to do, and miss "overview" type discussions.

The way the shared memory object is described, it reads that it is just that - shared. And so I'd assume that if a shared memory object is in multiple processes in a pool, it would be the *same* shared memory region, and the value would be accessible from all the processes.

>From there, for me at least, it's easy to proceed to the mistake of thinking that the global initialisation of the x and y variables creates the *same* shared memory objects in each process in the pool. Clearly it doesn't, hence this is "not a bug" but for me it's an easy mistake to make.

Maybe it would be enough just to add a comment to the shared memory object documentation that said "every shared memory object is independent - there is no way to create a reference to the same shared memory object in multiple processes, instead you need to create the object in one process and pass it to all of the others". That would probably have made me stop and think long enough to not make the mistake I did.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39255>
_______________________________________

From report at bugs.python.org  Wed Jan  8 15:16:23 2020
From: report at bugs.python.org (Jameson Nash)
Date: Wed, 08 Jan 2020 20:16:23 +0000
Subject: [issue39263] Windows Installer can't select TargetDir in UI?
In-Reply-To: <1578512167.47.0.555235356189.issue39263@roundup.psfhosted.org>
Message-ID: <1578514583.66.0.29970706727.issue39263@roundup.psfhosted.org>


Jameson Nash <vtjnash at gmail.com> added the comment:

Yes, I thought it was confusing that button is labeled "choose location and features", but it only let me change a few features and not location.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39263>
_______________________________________

From report at bugs.python.org  Wed Jan  8 16:04:49 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Wed, 08 Jan 2020 21:04:49 +0000
Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline
 string expressions
In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za>
Message-ID: <1578517489.04.0.562694212873.issue16806@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +17320
pull_request: https://github.com/python/cpython/pull/17582

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16806>
_______________________________________

From report at bugs.python.org  Wed Jan  8 16:12:49 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 08 Jan 2020 21:12:49 +0000
Subject: [issue16806] col_offset is -1 and lineno is wrong for multiline
 string expressions
In-Reply-To: <1356739702.66.0.625233113719.issue16806@psf.upfronthosting.co.za>
Message-ID: <1578517969.57.0.30425658038.issue16806@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> commit 995d9b92979768125ced4da3a56f755bcdf80f6e introduced a regression: bpo-37603: parsetok(): Assertion `(intptr_t)(int)(a - line_start) == (a - line_start)' failed, when running get-pip.py.

Fixed in https://bugs.python.org/issue39209

----------
nosy: +pablogsal
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16806>
_______________________________________

From report at bugs.python.org  Wed Jan  8 18:51:16 2020
From: report at bugs.python.org (Bar Harel)
Date: Wed, 08 Jan 2020 23:51:16 +0000
Subject: [issue39264] Fix UserDict.get to account for __missing__
Message-ID: <1578527476.03.0.196405087716.issue39264@roundup.psfhosted.org>


New submission from Bar Harel <bzvi7919 at gmail.com>:

Unlike dict, UserDict.__missing__ is called on .get().
After a discussion on the Python-Dev mailing list, mimicking dict's behavior was chosen as a solution to the issue.

----------
components: Library (Lib)
messages: 359633
nosy: bar.harel
priority: normal
severity: normal
status: open
title: Fix UserDict.get to account for __missing__
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39264>
_______________________________________

From report at bugs.python.org  Wed Jan  8 18:55:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 23:55:35 +0000
Subject: [issue39265] test_ssl failed on AMD64 RHEL8 Refleaks 2.7
Message-ID: <1578527735.81.0.0696130913832.issue39265@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

AMD64 RHEL8 Refleaks 2.7:
https://buildbot.python.org/all/#/builders/102/builds/45

test_protocol_sslv23 (test.test_ssl.ThreadedTests)
Connecting to an SSLv23 server with various client options ... 
 Could not scan /etc/ssl/openssl.cnf for MinProtocol: [Errno 2] No such file or directory: '/etc/ssl/openssl.cnf'

 PROTOCOL_TLS->PROTOCOL_TLS CERT_NONE
 PROTOCOL_TLSv1->PROTOCOL_TLS CERT_NONE
ERROR

Connecting to a TLSv1.1 server with various client options. ... 
 Could not scan /etc/ssl/openssl.cnf for MinProtocol: [Errno 2] No such file or directory: '/etc/ssl/openssl.cnf'

 PROTOCOL_TLSv1_1->PROTOCOL_TLSv1_1 CERT_NONE
 {PROTOCOL_TLS->PROTOCOL_TLSv1_1} CERT_NONE
 PROTOCOL_TLSv1_1->PROTOCOL_TLS CERT_NONE
ERROR


======================================================================
ERROR: test_protocol_sslv23 (test.test_ssl.ThreadedTests)
Connecting to an SSLv23 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/test/test_ssl.py", line 189, in f
    return func(*args, **kwargs)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/test/test_ssl.py", line 2402, in test_protocol_sslv23
    try_protocol_combo(ssl.PROTOCOL_SSLv23, ssl.PROTOCOL_TLSv1, 'TLSv1')
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/test/test_ssl.py", line 2134, in try_protocol_combo
    chatty=False, connectionchatty=False)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/test/test_ssl.py", line 2062, in server_params_test
    s.connect((HOST, server.port))
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/ssl.py", line 864, in connect
    self._real_connect(addr, False)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/ssl.py", line 855, in _real_connect
    self.do_handshake()
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/ssl.py", line 828, in do_handshake
    self._sslobj.do_handshake()
SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:727)

======================================================================
ERROR: test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1.1 server with various client options.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/test/test_ssl.py", line 189, in f
    return func(*args, **kwargs)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/test/test_ssl.py", line 2477, in test_protocol_tlsv1_1
    try_protocol_combo(ssl.PROTOCOL_SSLv23, ssl.PROTOCOL_TLSv1_1, 'TLSv1.1')
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/test/test_ssl.py", line 2134, in try_protocol_combo
    chatty=False, connectionchatty=False)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/test/test_ssl.py", line 2062, in server_params_test
    s.connect((HOST, server.port))
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/ssl.py", line 864, in connect
    self._real_connect(addr, False)
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/ssl.py", line 855, in _real_connect
    self.do_handshake()
  File "/home/buildbot/buildarea/2.7.cstratak-RHEL8-x86_64.refleak/build/Lib/ssl.py", line 828, in do_handshake
    self._sslobj.do_handshake()
SSLError: [SSL: TLSV1_ALERT_PROTOCOL_VERSION] tlsv1 alert protocol version (_ssl.c:727)

----------
assignee: christian.heimes
components: SSL, Tests
messages: 359634
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: test_ssl failed on AMD64 RHEL8 Refleaks 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39265>
_______________________________________

From report at bugs.python.org  Wed Jan  8 18:56:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 23:56:04 +0000
Subject: [issue39265] test_ssl failed on AMD64 RHEL8 Refleaks 2.7
In-Reply-To: <1578527735.81.0.0696130913832.issue39265@roundup.psfhosted.org>
Message-ID: <1578527764.61.0.879685266337.issue39265@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39265>
_______________________________________

From report at bugs.python.org  Wed Jan  8 18:59:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 08 Jan 2020 23:59:23 +0000
Subject: [issue39265] test_ssl failed on AMD64 RHEL8 Refleaks 2.7
In-Reply-To: <1578527735.81.0.0696130913832.issue39265@roundup.psfhosted.org>
Message-ID: <1578527963.1.0.166660625589.issue39265@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Note: it's not a regression, AMD64 RHEL8 Refleaks 2.7 is failing since build #1. Logs of oldest builds are no longer available, but I can see that test_ssl was already failing at build #10 (22 days ago, commit 5f2c1345a79f205c680ed6e0a6ed44199546d79e).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39265>
_______________________________________

From report at bugs.python.org  Wed Jan  8 19:00:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 00:00:09 +0000
Subject: [issue39265] test_ssl failed on AMD64 RHEL8 Refleaks 2.7
In-Reply-To: <1578527735.81.0.0696130913832.issue39265@roundup.psfhosted.org>
Message-ID: <1578528009.22.0.673519204327.issue39265@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, I even already reported this issue as bpo-38338 :-)

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> [2.7] test_ssl fails on RHEL8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39265>
_______________________________________

From report at bugs.python.org  Wed Jan  8 19:00:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 00:00:37 +0000
Subject: [issue38338] [2.7] test_ssl fails on RHEL8
In-Reply-To: <1569934554.24.0.56143952582.issue38338@roundup.psfhosted.org>
Message-ID: <1578528037.47.0.0731226163452.issue38338@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-39265 as a duplicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38338>
_______________________________________

From report at bugs.python.org  Wed Jan  8 19:01:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 00:01:01 +0000
Subject: [issue38338] [2.7] test_ssl: test_protocol_sslv23() and
 test_protocol_tlsv1_1() fail on RHEL8
In-Reply-To: <1569934554.24.0.56143952582.issue38338@roundup.psfhosted.org>
Message-ID: <1578528061.44.0.671326574192.issue38338@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: [2.7] test_ssl fails on RHEL8 -> [2.7] test_ssl: test_protocol_sslv23() and test_protocol_tlsv1_1() fail on RHEL8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38338>
_______________________________________

From report at bugs.python.org  Wed Jan  8 19:03:05 2020
From: report at bugs.python.org (Bar Harel)
Date: Thu, 09 Jan 2020 00:03:05 +0000
Subject: [issue39264] Fix UserDict.get to account for __missing__
In-Reply-To: <1578527476.03.0.196405087716.issue39264@roundup.psfhosted.org>
Message-ID: <1578528185.79.0.710419608661.issue39264@roundup.psfhosted.org>


Change by Bar Harel <bzvi7919 at gmail.com>:


----------
keywords: +patch
pull_requests: +17321
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17910

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39264>
_______________________________________

From report at bugs.python.org  Wed Jan  8 19:04:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 00:04:08 +0000
Subject: [issue39266] [2.7] test_bsddb3 leaked [1, 1,
 1] file descriptors on AMD64 RHEL7 Refleaks 2.7
Message-ID: <1578528248.0.0.1734131404.issue39266@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

AMD64 RHEL7 Refleaks 2.7:
https://buildbot.python.org/all/#/builders/51/builds/13

test_bsddb3 leaked [1, 1, 1] file descriptors, sum=3

----------
components: Tests
messages: 359638
nosy: vstinner
priority: normal
severity: normal
status: open
title: [2.7] test_bsddb3 leaked [1, 1, 1] file descriptors on AMD64 RHEL7 Refleaks 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39266>
_______________________________________

From report at bugs.python.org  Wed Jan  8 19:06:08 2020
From: report at bugs.python.org (Bar Harel)
Date: Thu, 09 Jan 2020 00:06:08 +0000
Subject: [issue39267] Fix dict's __missing__ documentation
Message-ID: <1578528368.02.0.98072411611.issue39267@roundup.psfhosted.org>


New submission from Bar Harel <bzvi7919 at gmail.com>:

Continuing bpo-39264, and according to the mailing list discussion at Python-Dev.
Fixing dict's __missing__ documentation. Clarify .get() does not call __missing__, and move __missing__ from the data model to dict's section as it's not a general object or ABC method but a dict-only implementation.

----------
assignee: docs at python
components: Documentation
messages: 359639
nosy: bar.harel, docs at python
priority: normal
severity: normal
status: open
title: Fix dict's __missing__ documentation
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39267>
_______________________________________

From report at bugs.python.org  Wed Jan  8 19:10:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 00:10:59 +0000
Subject: [issue39268] test_asyncio: test_create_server_ssl_verified() failed
 on AMD64 FreeBSD Non-Debug 3.x
Message-ID: <1578528659.39.0.760822597005.issue39268@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

AMD64 FreeBSD Non-Debug 3.x:
https://buildbot.python.org/all/#/builders/214/builds/123

======================================================================
ERROR: test_create_server_ssl_verified (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-9e36.nondebug/build/Lib/test/test_asyncio/test_events.py", line 1106, in test_create_server_ssl_verified
    proto.transport.close()
AttributeError: 'NoneType' object has no attribute 'close'

----------
components: Tests, asyncio
messages: 359640
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio: test_create_server_ssl_verified() failed on AMD64 FreeBSD Non-Debug 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39268>
_______________________________________

From report at bugs.python.org  Wed Jan  8 19:12:16 2020
From: report at bugs.python.org (Bar Harel)
Date: Thu, 09 Jan 2020 00:12:16 +0000
Subject: [issue39267] Fix dict's __missing__ documentation
In-Reply-To: <1578528368.02.0.98072411611.issue39267@roundup.psfhosted.org>
Message-ID: <1578528736.18.0.154698249244.issue39267@roundup.psfhosted.org>


Change by Bar Harel <bzvi7919 at gmail.com>:


----------
keywords: +patch
pull_requests: +17322
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17911

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39267>
_______________________________________

From report at bugs.python.org  Wed Jan  8 19:12:54 2020
From: report at bugs.python.org (Bar Harel)
Date: Thu, 09 Jan 2020 00:12:54 +0000
Subject: [issue39264] Fix UserDict.get to account for __missing__
In-Reply-To: <1578527476.03.0.196405087716.issue39264@roundup.psfhosted.org>
Message-ID: <1578528774.45.0.484890164316.issue39264@roundup.psfhosted.org>


Bar Harel <bzvi7919 at gmail.com> added the comment:

See also bpo-39267

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39264>
_______________________________________

From report at bugs.python.org  Wed Jan  8 19:54:32 2020
From: report at bugs.python.org (wim glenn)
Date: Thu, 09 Jan 2020 00:54:32 +0000
Subject: [issue36761] Extended slice assignment + iterable unpacking
In-Reply-To: <1556650082.38.0.163364239874.issue36761@roundup.psfhosted.org>
Message-ID: <1578531272.48.0.890420620428.issue36761@roundup.psfhosted.org>


Change by wim glenn <wim.glenn at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36761>
_______________________________________

From report at bugs.python.org  Wed Jan  8 19:56:03 2020
From: report at bugs.python.org (wim glenn)
Date: Thu, 09 Jan 2020 00:56:03 +0000
Subject: [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1578531363.45.0.874817472789.issue28617@roundup.psfhosted.org>


Change by wim glenn <wim.glenn at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28617>
_______________________________________

From report at bugs.python.org  Wed Jan  8 20:02:13 2020
From: report at bugs.python.org (wim glenn)
Date: Thu, 09 Jan 2020 01:02:13 +0000
Subject: [issue39269] Descriptor how-to guide wanting update for 3.6+ features
Message-ID: <1578531733.6.0.729486446761.issue39269@roundup.psfhosted.org>


New submission from wim glenn <wim.glenn at gmail.com>:

https://docs.python.org/3/howto/descriptor.html

Current descriptor how-to guide, above, has no mention about API features added since Python 3.6 (see __set_name__ in PEP 487)

It's an important and useful piece of using descriptors effectively and the guide could be updated to include some info about that. 

There's some info in datamodel.html (e.g. 3.3.3.6. Creating the class object) but a mention in the how-to guide would be welcome too.

----------
assignee: docs at python
components: Documentation
messages: 359642
nosy: docs at python, wim.glenn
priority: normal
severity: normal
status: open
title: Descriptor how-to guide wanting update for 3.6+ features
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39269>
_______________________________________

From report at bugs.python.org  Wed Jan  8 20:18:06 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jan 2020 01:18:06 +0000
Subject: [issue39269] Descriptor how-to guide wanting update for 3.6+ features
In-Reply-To: <1578531733.6.0.729486446761.issue39269@roundup.psfhosted.org>
Message-ID: <1578532686.11.0.194915476645.issue39269@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39269>
_______________________________________

From report at bugs.python.org  Wed Jan  8 20:19:46 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jan 2020 01:19:46 +0000
Subject: [issue39269] Descriptor how-to guide wanting update for 3.6+ features
In-Reply-To: <1578531733.6.0.729486446761.issue39269@roundup.psfhosted.org>
Message-ID: <1578532786.66.0.934942778943.issue39269@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems like a duplicate of https://bugs.python.org/issue34394

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39269>
_______________________________________

From report at bugs.python.org  Wed Jan  8 20:45:04 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 09 Jan 2020 01:45:04 +0000
Subject: [issue39260] distutils.spawn: find_executable() Fails To Find Many
 Executables on Windows
In-Reply-To: <1578498792.76.0.781232335261.issue39260@roundup.psfhosted.org>
Message-ID: <1578534304.72.0.750763393728.issue39260@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

The problem is that distutils.spawn.find_executable is an internal API, never meant for general usage.

Only minimal change happens to distutils these days, partly because the codebase is full of dark corners and weird interactions (so a fix can easily break someone else?s setup.py script), partly because few core developers have the expertise and willingess to write patches or review PRs.

So the question is: is the problem you reported a problem that happens when people write setup.py scripts, or when using the function for something else?  If it?s the latter, I?m afraid the safe course of action would be to change nothing, and recommend people use truly general-use functions like shutil.which.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39260>
_______________________________________

From report at bugs.python.org  Wed Jan  8 21:00:45 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 09 Jan 2020 02:00:45 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578535245.44.0.473096866367.issue39259@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17323
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17912

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Wed Jan  8 21:19:10 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 09 Jan 2020 02:19:10 +0000
Subject: [issue39269] Descriptor how-to guide wanting update for 3.6+ features
In-Reply-To: <1578531733.6.0.729486446761.issue39269@roundup.psfhosted.org>
Message-ID: <1578536350.14.0.904473618468.issue39269@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the reminder.
I'll have time soon to work on this.
Since the other tracker issue cover this,
will close this one as a duplicate.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39269>
_______________________________________

From report at bugs.python.org  Wed Jan  8 21:22:24 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 09 Jan 2020 02:22:24 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578536544.03.0.0168281995958.issue39259@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

ftplib: https://github.com/python/cpython/blob/efa3b51fd060352cc6220b27a1026e4d4d5401bd/Lib/ftplib.py#L155
nntplib: https://github.com/python/cpython/blob/2e6a8efa837410327b593dc83c57492253b1201e/Lib/nntplib.py#L1049
smtplib: https://github.com/python/cpython/blob/3faf826e5879536d2272f1a51c58965a16827f81/Lib/smtplib.py#L386


I found more things that depends on socket.makefile.
IMHO, we can apply this change to those modules. What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Wed Jan  8 21:34:08 2020
From: report at bugs.python.org (Thomas Passin)
Date: Thu, 09 Jan 2020 02:34:08 +0000
Subject: [issue39260] distutils.spawn: find_executable() Fails To Find Many
 Executables on Windows
In-Reply-To: <1578498792.76.0.781232335261.issue39260@roundup.psfhosted.org>
Message-ID: <1578537248.59.0.489644670177.issue39260@roundup.psfhosted.org>


Thomas Passin <pub1 at tompassin.net> added the comment:

I came across it while working on some code running in the Leo editor.  I had no idea it was not really public; I just assumed that someone knew something I didn't.  Then I discovered that it couldn't find some files I  thought it clearly should, and wrote the issue, thinking it might help someone else who didn't know the limitations.

But from what you say, I see it will be better to use another way, and to leave this bit alone.  Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39260>
_______________________________________

From report at bugs.python.org  Wed Jan  8 21:47:01 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 09 Jan 2020 02:47:01 +0000
Subject: [issue39261] Dead assignment in pyinit_config
In-Reply-To: <1578507115.64.0.589303193818.issue39261@roundup.psfhosted.org>
Message-ID: <1578538021.73.0.800378470158.issue39261@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 2c7ed417a4c758f1c3f97fcbca70a49f79e58c07 by Benjamin Peterson (Alex Henrie) in branch 'master':
closes bpo-39261: Remove dead assignment from pyinit_config. (GH-17907)
https://github.com/python/cpython/commit/2c7ed417a4c758f1c3f97fcbca70a49f79e58c07


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39261>
_______________________________________

From report at bugs.python.org  Wed Jan  8 21:48:56 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 09 Jan 2020 02:48:56 +0000
Subject: [issue39262] Unused error message in _sharedexception_bind
In-Reply-To: <1578507749.56.0.495941888024.issue39262@roundup.psfhosted.org>
Message-ID: <1578538136.29.0.0898738369764.issue39262@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 5cae042f686cc174e00093944dc118914c874b7c by Benjamin Peterson (Alex Henrie) in branch 'master':
closes bpo-39262: Use specific out-of-memory message in _sharedexception_bind. (GH-17908)
https://github.com/python/cpython/commit/5cae042f686cc174e00093944dc118914c874b7c


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39262>
_______________________________________

From report at bugs.python.org  Wed Jan  8 21:49:13 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jan 2020 02:49:13 +0000
Subject: [issue39262] Unused error message in _sharedexception_bind
In-Reply-To: <1578507749.56.0.495941888024.issue39262@roundup.psfhosted.org>
Message-ID: <1578538153.74.0.690890128349.issue39262@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17325
pull_request: https://github.com/python/cpython/pull/17913

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39262>
_______________________________________

From report at bugs.python.org  Wed Jan  8 21:59:51 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 09 Jan 2020 02:59:51 +0000
Subject: [issue39150] See if PyToken_OneChar would be faster as a lookup table
In-Reply-To: <1577583921.53.0.126418549221.issue39150@roundup.psfhosted.org>
Message-ID: <1578538791.41.0.111368876886.issue39150@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

I tried out some experimenting with the lookup table vs. the switch
statement.

The relevant diff (not including the patches to the code generator) is:


--- Parser/token.c
+++ Parser/token.c
@@ -77,31 +77,36 @@
 int
 PyToken_OneChar(int c1)
 {
-    switch (c1) {
-    case '%': return PERCENT;
-    case '&': return AMPER;
-    case '(': return LPAR;
-    case ')': return RPAR;
-    case '*': return STAR;
-    case '+': return PLUS;
-    case ',': return COMMA;
-    case '-': return MINUS;
-    case '.': return DOT;
-    case '/': return SLASH;
-    case ':': return COLON;
-    case ';': return SEMI;
-    case '<': return LESS;
-    case '=': return EQUAL;
-    case '>': return GREATER;
-    case '@': return AT;
-    case '[': return LSQB;
-    case ']': return RSQB;
-    case '^': return CIRCUMFLEX;
-    case '{': return LBRACE;
-    case '|': return VBAR;
-    case '}': return RBRACE;
-    case '~': return TILDE;
-    }
+    static char op_lookup[] = {
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        PERCENT,   AMPER,     OP,
+        LPAR,      RPAR,      STAR,      PLUS,      COMMA,
+        MINUS,     DOT,       SLASH,     OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        COLON,     SEMI,
+        LESS,      EQUAL,     GREATER,   OP,        AT,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        LSQB,      OP,        RSQB,      CIRCUMFLEX,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        OP,        OP,
+        OP,        OP,        OP,        LBRACE,    VBAR,
+        RBRACE,    TILDE
+    };
+    if (c1>=37 && c1<=126)
+        return op_lookup[c1];
     return OP;
 }

To test the speed change, I couldn't use pyperformance, because the only
thing I wanted to time was the In my testing, I didn't use pyperformance
because the only part of the code I wanted to test was the actual
compilation of the code.  My solution for this was to find the 100 largest
*.py files in the cpython repo and compile them like so:

    python -m py_compile $(List-of-big-*.py-files)

The speedup was significant: My table-driven lookup ran the compile tests
about 10% than the existing switch approach.  That was without
--enable-optimizations in my configure.

However, as pablogsal suspected, with PGO enabled, the two approaches ran
the code in pretty much the same speed.

I do think that there may be merit in using a table-driven approach that
generates less code and doesn't rely on PGO speeding things up.

If anyone's interested, all my work is on branch Issue39150 in my fork
petdance/cpython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39150>
_______________________________________

From report at bugs.python.org  Wed Jan  8 22:07:44 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jan 2020 03:07:44 +0000
Subject: [issue39262] Unused error message in _sharedexception_bind
In-Reply-To: <1578507749.56.0.495941888024.issue39262@roundup.psfhosted.org>
Message-ID: <1578539264.79.0.181471977651.issue39262@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 45e5750a013291c5729e0ebad2b9e340fdffbd36 by Miss Islington (bot) in branch '3.8':
closes bpo-39262: Use specific out-of-memory message in _sharedexception_bind. (GH-17908)
https://github.com/python/cpython/commit/45e5750a013291c5729e0ebad2b9e340fdffbd36


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39262>
_______________________________________

From report at bugs.python.org  Wed Jan  8 23:14:48 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 09 Jan 2020 04:14:48 +0000
Subject: [issue39270] Dead assignment in config_init_module_search_paths
Message-ID: <1578543288.1.0.568310350054.issue39270@roundup.psfhosted.org>


New submission from Alex Henrie <alexhenrie24 at gmail.com>:

config_init_module_search_paths currently has the following code:

    const wchar_t *p = sys_path;
    while (1) {
        p = wcschr(sys_path, delim);

The first assignment to p is unnecessary because it is immediately overwritten. Victor Stinner suggested moving the variable declaration into the loop itself to clarify that it does not need to be initialized elsewhere: https://github.com/python/cpython/pull/16267/files#r364216448

----------
messages: 359652
nosy: alex.henrie
priority: normal
severity: normal
status: open
title: Dead assignment in config_init_module_search_paths
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39270>
_______________________________________

From report at bugs.python.org  Wed Jan  8 23:17:04 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 09 Jan 2020 04:17:04 +0000
Subject: [issue39270] Dead assignment in config_init_module_search_paths
In-Reply-To: <1578543288.1.0.568310350054.issue39270@roundup.psfhosted.org>
Message-ID: <1578543424.56.0.635772155782.issue39270@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
keywords: +patch
pull_requests: +17326
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17914

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39270>
_______________________________________

From report at bugs.python.org  Wed Jan  8 23:22:03 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 09 Jan 2020 04:22:03 +0000
Subject: [issue39271] Dead assignment in pattern_subx
Message-ID: <1578543723.64.0.00400211549211.issue39271@roundup.psfhosted.org>


New submission from Alex Henrie <alexhenrie24 at gmail.com>:

The function pattern_subx currently sets the variable b to charsize, but that variable is reset to STATE_OFFSET(&state, state.start) before it is ever used.

----------
components: Regular Expressions
messages: 359653
nosy: alex.henrie, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Dead assignment in pattern_subx
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39271>
_______________________________________

From report at bugs.python.org  Wed Jan  8 23:23:33 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 09 Jan 2020 04:23:33 +0000
Subject: [issue39271] Dead assignment in pattern_subx
In-Reply-To: <1578543723.64.0.00400211549211.issue39271@roundup.psfhosted.org>
Message-ID: <1578543813.92.0.527542389674.issue39271@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
keywords: +patch
pull_requests: +17327
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17915

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39271>
_______________________________________

From report at bugs.python.org  Wed Jan  8 23:27:44 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 09 Jan 2020 04:27:44 +0000
Subject: [issue39272] Dead assignment in
 _ssl__SSLContext_load_verify_locations_impl
Message-ID: <1578544064.68.0.445985334082.issue39272@roundup.psfhosted.org>


New submission from Alex Henrie <alexhenrie24 at gmail.com>:

The function _ssl__SSLContext_load_verify_locations_impl currently contains the following code:

        if (r != 1) {
            ok = 0;
            if (errno != 0) {
                ERR_clear_error();
                PyErr_SetFromErrno(PyExc_OSError);
            }
            else {
                _setSSLError(NULL, 0, __FILE__, __LINE__);
            }
            goto error;
        }
    }
    goto end;

  error:
    ok = 0;

It is unnecessary to set ok to 0 before jumping to error because the first instruction after the error label does the same thing.

----------
assignee: christian.heimes
components: SSL
messages: 359654
nosy: alex.henrie, christian.heimes
priority: normal
severity: normal
status: open
title: Dead assignment in _ssl__SSLContext_load_verify_locations_impl
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39272>
_______________________________________

From report at bugs.python.org  Wed Jan  8 23:28:33 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 09 Jan 2020 04:28:33 +0000
Subject: [issue39272] Dead assignment in
 _ssl__SSLContext_load_verify_locations_impl
In-Reply-To: <1578544064.68.0.445985334082.issue39272@roundup.psfhosted.org>
Message-ID: <1578544113.1.0.166239592708.issue39272@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
keywords: +patch
pull_requests: +17328
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17916

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39272>
_______________________________________

From report at bugs.python.org  Thu Jan  9 01:27:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jan 2020 06:27:58 +0000
Subject: [issue39271] Dead assignment in pattern_subx
In-Reply-To: <1578543723.64.0.00400211549211.issue39271@roundup.psfhosted.org>
Message-ID: <1578551278.81.0.766031264384.issue39271@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 1a183faccbe5c32c367dbced721a25c1444dc5c1 by Serhiy Storchaka (Alex Henrie) in branch 'master':
bpo-39271: Remove dead assignment from pattern_subx (GH-17915)
https://github.com/python/cpython/commit/1a183faccbe5c32c367dbced721a25c1444dc5c1


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39271>
_______________________________________

From report at bugs.python.org  Thu Jan  9 01:29:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jan 2020 06:29:10 +0000
Subject: [issue39271] Dead assignment in pattern_subx
In-Reply-To: <1578543723.64.0.00400211549211.issue39271@roundup.psfhosted.org>
Message-ID: <1578551350.89.0.910555077814.issue39271@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you Alex.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39271>
_______________________________________

From report at bugs.python.org  Thu Jan  9 01:59:01 2020
From: report at bugs.python.org (Michael Yoo)
Date: Thu, 09 Jan 2020 06:59:01 +0000
Subject: [issue39273] ncurses does not include BUTTON5_* constants
Message-ID: <1578553141.45.0.141104357774.issue39273@roundup.psfhosted.org>


New submission from Michael Yoo <michael.yoo at akunacapital.com>:

Hi,

Recently I was working with ncurses, and when handling the mouse scroll events, I noticed that the curses library does not include the BUTTON5_* macros provided by ncurses. On my system, BUTTON5 corresponds to the mouse down event.

Is there a reason for this, or has it just not been updated? If so, the expectation is that it exists.

Relevant source location: https://github.com/python/cpython/blob/2bc3434/Modules/_cursesmodule.c#L4668

----------
components: Library (Lib)
messages: 359657
nosy: michael.yoo at akunacapital.com
priority: normal
severity: normal
status: open
title: ncurses does not include BUTTON5_* constants
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/issue39273>
_______________________________________

From report at bugs.python.org  Thu Jan  9 04:12:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 09:12:32 +0000
Subject: [issue39272] Dead assignment in
 _ssl__SSLContext_load_verify_locations_impl
In-Reply-To: <1578544064.68.0.445985334082.issue39272@roundup.psfhosted.org>
Message-ID: <1578561152.45.0.820264617225.issue39272@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a1c1be24cb3ae25b5b53e9dc94d6327009626283 by Victor Stinner (Alex Henrie) in branch 'master':
bpo-39272: Remove dead assignment from _ssl__SSLContext_load_verify_locations_impl (GH-17916)
https://github.com/python/cpython/commit/a1c1be24cb3ae25b5b53e9dc94d6327009626283


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39272>
_______________________________________

From report at bugs.python.org  Thu Jan  9 04:12:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 09:12:42 +0000
Subject: [issue39272] Dead assignment in
 _ssl__SSLContext_load_verify_locations_impl
In-Reply-To: <1578544064.68.0.445985334082.issue39272@roundup.psfhosted.org>
Message-ID: <1578561162.83.0.28563025658.issue39272@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39272>
_______________________________________

From report at bugs.python.org  Thu Jan  9 04:14:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 09:14:15 +0000
Subject: [issue39270] Dead assignment in config_init_module_search_paths
In-Reply-To: <1578543288.1.0.568310350054.issue39270@roundup.psfhosted.org>
Message-ID: <1578561255.2.0.0404609146893.issue39270@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset f3e5e9566989635225d1b91088888074fc260817 by Victor Stinner (Alex Henrie) in branch 'master':
bpo-39270: Remove dead assignment from config_init_module_search_paths (GH-17914)
https://github.com/python/cpython/commit/f3e5e9566989635225d1b91088888074fc260817


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39270>
_______________________________________

From report at bugs.python.org  Thu Jan  9 04:14:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 09:14:32 +0000
Subject: [issue39270] Dead assignment in config_init_module_search_paths
In-Reply-To: <1578543288.1.0.568310350054.issue39270@roundup.psfhosted.org>
Message-ID: <1578561272.54.0.425950828447.issue39270@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39270>
_______________________________________

From report at bugs.python.org  Thu Jan  9 04:18:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 09:18:40 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578561520.13.0.661584753408.issue39259@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

ftplib: https://github.com/python/cpython/blob/efa3b51fd060352cc6220b27a1026e4d4d5401bd/Lib/ftplib.py#L155
nntplib: https://github.com/python/cpython/blob/2e6a8efa837410327b593dc83c57492253b1201e/Lib/nntplib.py#L1049
smtplib: https://github.com/python/cpython/blob/3faf826e5879536d2272f1a51c58965a16827f81/Lib/smtplib.py#L386

It seems like these 3 modules use makefile() and have a timeout parameter. If makefile() doesn't support non-blocking mode, sure, it's a good idea to also reject explicitly timeout=0 in these modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Thu Jan  9 05:25:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 10:25:09 +0000
Subject: [issue39029] TestMaildir.test_clean fails randomly under parallel
 tests
In-Reply-To: <1576141174.61.0.510141920657.issue39029@roundup.psfhosted.org>
Message-ID: <1578565509.48.0.553385629885.issue39029@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> yes, the test uses support.TESTFN which has the value of "{}_{}_tmp".format(TESTFN, os.getpid()) in the setUp [0] to create tempdir. Under parallel tests the pid value of TESTFN is initialised with a pid once and used always in the setup calls. So setup acts under parallel tests with same test folder. The tempdir can be dynamically generated but I guess this pattern to use support.TESTFN is common and there could be other flaky tests.

I don't understand. Let's say that test_mailbox and test_os are run in parallel, process 1 runs test_mailbox and process 2 runs test_os. TESTFN should be different in each process but globally unique.

So I don't understand the difference between:

-        self._path = support.TESTFN

and:

+        self._tempdir = tempfile.TemporaryDirectory()
+        self._path = self._tempdir.name

Is it because the test currently doesn't remove self._path directory in some cases?

You wrote "I guess the file is not really deleted in some cases." I think that this should be investigated first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39029>
_______________________________________

From report at bugs.python.org  Thu Jan  9 05:26:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 10:26:19 +0000
Subject: [issue39154] "utf8" not always a synonym for "utf-8" in lib2to3
In-Reply-To: <1577641682.29.0.16123079146.issue39154@roundup.psfhosted.org>
Message-ID: <1578565579.1.0.704875529608.issue39154@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39154>
_______________________________________

From report at bugs.python.org  Thu Jan  9 05:30:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jan 2020 10:30:03 +0000
Subject: [issue39029] TestMaildir.test_clean fails randomly under parallel
 tests
In-Reply-To: <1576141174.61.0.510141920657.issue39029@roundup.psfhosted.org>
Message-ID: <1578565803.44.0.981230754727.issue39029@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If TESTFN is the same in different processes, there is something wrong in the code for running parallel tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39029>
_______________________________________

From report at bugs.python.org  Thu Jan  9 05:31:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 09 Jan 2020 10:31:22 +0000
Subject: [issue39150] See if PyToken_OneChar would be faster as a lookup table
In-Reply-To: <1577583921.53.0.126418549221.issue39150@roundup.psfhosted.org>
Message-ID: <1578565882.5.0.173411869425.issue39150@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I will take a look and try to reproduce the benchmarks result you mentioned, but if under PGO there is no substantial performance increase is much less appealing as the lookup table code is less clear and maintainable than the simple switch. Also you have a branch that is a good candidate to trigger the same branch mispredictions as the default of the switch (c1>=37 && c1<=126).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39150>
_______________________________________

From report at bugs.python.org  Thu Jan  9 05:36:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jan 2020 10:36:03 +0000
Subject: [issue39150] See if PyToken_OneChar would be faster as a lookup table
In-Reply-To: <1577583921.53.0.126418549221.issue39150@roundup.psfhosted.org>
Message-ID: <1578566163.93.0.613437604887.issue39150@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The difference around 10% looks very strange. Tokenizing is just one of parts of the compiler, and unlikely it is a narrow way. There are input/output, many memory allocations, encoding and decoding, many iterations and recursions. Are you sure that you run benchmarks in the same environment, multiple times, and got stable results? Could you provide a script that reproduces this?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39150>
_______________________________________

From report at bugs.python.org  Thu Jan  9 05:49:37 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jan 2020 10:49:37 +0000
Subject: [issue39029] TestMaildir.test_clean fails randomly under parallel
 tests
In-Reply-To: <1576141174.61.0.510141920657.issue39029@roundup.psfhosted.org>
Message-ID: <1578566977.6.0.643633342156.issue39029@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> You wrote "I guess the file is not really deleted in some cases." I think that this should be investigated first.

Sorry, I wanted to mean that as the test deletes the file and goes on to assert it's not present the other test that runs in parallel creates the same file in setup code. Thus I wanted to imply that during assertion and parallel test's setup code the directory is again created.

I tried printing os.getpid() and support.TESTFN values in the setup and they are the same for all the tests.


./python.exe -Wall -m test -R 4:4 -j 4 test_mailbox -m test_clean
0:00:00 load avg: 2.91 Run tests in parallel using 4 child processes
0:00:00 load avg: 2.91 [1/1/1] test_mailbox failed
os.getpid() = 27901
support.TESTFN = '@test_27901_tmp'
os.getpid() = 27901
support.TESTFN = '@test_27901_tmp'
beginning 8 repetitions
12345678
.test test_mailbox failed -- Traceback (most recent call last):
  File "/Users/kasingar/stuff/python/cpython/Lib/test/test_mailbox.py", line 740, in test_clean
    self.assertFalse(os.path.exists(foo_path))
AssertionError: True is not false

== Tests result: FAILURE ==

1 test failed:
    test_mailbox

Total duration: 789 ms
Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39029>
_______________________________________

From report at bugs.python.org  Thu Jan  9 06:04:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 11:04:07 +0000
Subject: [issue39029] TestMaildir.test_clean fails randomly under parallel
 tests
In-Reply-To: <1576141174.61.0.510141920657.issue39029@roundup.psfhosted.org>
Message-ID: <1578567847.88.0.940730668156.issue39029@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

./python.exe -Wall -m test -R 4:4 -j 4 test_mailbox -m test_clean

With this command: test_mailbox is run exactly once. It's not run in parallel. But the same test is run 8 times.

os.getpid() = 27901
support.TESTFN = '@test_27901_tmp'
os.getpid() = 27901
support.TESTFN = '@test_27901_tmp'

That sounds consistent: same pid means same TESTFN.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39029>
_______________________________________

From report at bugs.python.org  Thu Jan  9 06:10:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 11:10:56 +0000
Subject: [issue39029] TestMaildir.test_clean fails randomly under parallel
 tests
In-Reply-To: <1576141174.61.0.510141920657.issue39029@roundup.psfhosted.org>
Message-ID: <1578568256.03.0.889552470297.issue39029@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I failed to reproduce the issue on my Fedora 31 laptop using 20 processes running on parallel (my CPU has 4 cores: 8 threads).

vstinner at apu$ ./python -Wall -m test -R 3:3 -j 20 test_mailbox -m test_clean -F
0:00:00 load avg: 14.86 Run tests in parallel using 20 child processes
(...)
0:01:12 load avg: 18.81 [321] test_mailbox passed
beginning 6 repetitions
123456
......
^C
Kill <TestWorkerProcess #1 running test=test_mailbox pid=82501 time=2.2 sec> process group
Kill <TestWorkerProcess #2 running test=test_mailbox pid=82485 time=4.1 sec> process group
Kill <TestWorkerProcess #3 running test=test_mailbox pid=82499 time=2.5 sec> process group
Kill <TestWorkerProcess #4 running test=test_mailbox pid=82525 time=131 ms> process group
Kill <TestWorkerProcess #5 running test=test_mailbox pid=82504 time=1.8 sec> process group
Kill <TestWorkerProcess #6 running test=test_mailbox pid=82514 time=761 ms> process group
Kill <TestWorkerProcess #7 running test=test_mailbox pid=82522 time=239 ms> process group
Kill <TestWorkerProcess #8 running test=test_mailbox pid=82509 time=1.3 sec> process group
Kill <TestWorkerProcess #9 running test=test_mailbox pid=82523 time=194 ms> process group
Kill <TestWorkerProcess #10 running test=test_mailbox pid=82513 time=787 ms> process group
Kill <TestWorkerProcess #11 running test=test_mailbox pid=82495 time=3.0 sec> process group
Kill <TestWorkerProcess #12 running test=test_mailbox pid=82515 time=674 ms> process group
Kill <TestWorkerProcess #13 running test=test_mailbox pid=82483 time=4.2 sec> process group
Kill <TestWorkerProcess #14 running test=test_mailbox pid=82482 time=4.3 sec> process group
Kill <TestWorkerProcess #15 running test=test_mailbox pid=82487 time=3.7 sec> process group
Kill <TestWorkerProcess #16 running test=test_mailbox pid=82492 time=3.3 sec> process group
Kill <TestWorkerProcess #17 running test=test_mailbox pid=82491 time=3.4 sec> process group
Kill <TestWorkerProcess #18 running test=test_mailbox pid=82500 time=2.4 sec> process group
Kill <TestWorkerProcess #19 running test=test_mailbox pid=82494 time=3.1 sec> process group
Kill <TestWorkerProcess #20 running test=test_mailbox pid=82506 time=1.5 sec> process group

== Tests result: INTERRUPTED ==
Test suite interrupted by signal SIGINT.

321 tests OK.

Total duration: 1 min 12 sec
Tests result: INTERRUPTED

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39029>
_______________________________________

From report at bugs.python.org  Thu Jan  9 06:18:14 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jan 2020 11:18:14 +0000
Subject: [issue39029] TestMaildir.test_clean fails randomly under parallel
 tests
In-Reply-To: <1576141174.61.0.510141920657.issue39029@roundup.psfhosted.org>
Message-ID: <1578568694.99.0.681611427879.issue39029@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I am able to reproduce it on my Mac and as below the values of os.getpid() are the same with the command. I will try to get to a Linux box to see if I can reproduce this. I was always under the assumption that -j 4 runs tests in parallel as it even says in the message "run tests in parallel using n child processes" . Maybe I am stumbling upon a mac os specific issue or understanding something wrong about the regrtest framework. I am using Macbook pro with Mojave.

./python.exe -Wall -m test -R 3:3 -j 20 test_mailbox -m test_clean -F
0:00:00 load avg: 2.31 Run tests in parallel using 20 child processes
0:00:03 load avg: 2.85 [  1/1] test_mailbox failed
os.getpid() = 37760
support.TESTFN = '@test_37760_tmp'
os.getpid() = 37760
support.TESTFN = '@test_37760_tmp'
beginning 6 repetitions
123456
.test test_mailbox failed -- Traceback (most recent call last):
  File "/Users/kasingar/stuff/python/cpython/Lib/test/test_mailbox.py", line 743, in test_clean
    self.assertFalse(os.path.exists(foo_path))
AssertionError: True is not false
Kill <TestWorkerProcess #2 running test=test_mailbox pid=37761 time=3.4 sec> process group
Kill <TestWorkerProcess #3 running test=test_mailbox pid=37763 time=3.4 sec> process group
Kill <TestWorkerProcess #4 running test=test_mailbox pid=37762 time=3.4 sec> process group
Kill <TestWorkerProcess #5 running test=test_mailbox pid=37764 time=3.4 sec> process group
Kill <TestWorkerProcess #6 running test=test_mailbox pid=37765 time=3.4 sec> process group
Kill <TestWorkerProcess #7 running test=test_mailbox pid=37766 time=3.4 sec> process group
Kill <TestWorkerProcess #8 running test=test_mailbox pid=37767 time=3.4 sec> process group
Kill <TestWorkerProcess #9 running test=test_mailbox pid=37768 time=3.3 sec> process group
Kill <TestWorkerProcess #10 running test=test_mailbox pid=37769 time=3.3 sec> process group
Kill <TestWorkerProcess #11 running test=test_mailbox pid=37770 time=3.3 sec> process group
Kill <TestWorkerProcess #12 running test=test_mailbox pid=37771 time=3.3 sec> process group
Kill <TestWorkerProcess #13 running test=test_mailbox pid=37772 time=3.2 sec> process group
Kill <TestWorkerProcess #14 running test=test_mailbox pid=37773 time=3.2 sec> process group
Kill <TestWorkerProcess #15 running test=test_mailbox pid=37774 time=3.2 sec> process group
Kill <TestWorkerProcess #16 running test=test_mailbox pid=37775 time=3.2 sec> process group
Kill <TestWorkerProcess #17 running test=test_mailbox pid=37776 time=3.2 sec> process group
Kill <TestWorkerProcess #18 running test=test_mailbox pid=37777 time=3.2 sec> process group
Kill <TestWorkerProcess #19 running test=test_mailbox pid=37778 time=3.2 sec> process group
Kill <TestWorkerProcess #20 running test=test_mailbox pid=37779 time=3.2 sec> process group

== Tests result: FAILURE ==

1 test failed:
    test_mailbox

Total duration: 3.4 sec
Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39029>
_______________________________________

From report at bugs.python.org  Thu Jan  9 06:21:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 11:21:28 +0000
Subject: [issue39029] TestMaildir.test_clean fails randomly under parallel
 tests
In-Reply-To: <1576141174.61.0.510141920657.issue39029@roundup.psfhosted.org>
Message-ID: <1578568888.72.0.401440323535.issue39029@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I was always under the assumption that -j 4 runs tests in parallel

If you run one test file, even with -j1000, only one test file will be run in parallel :-)

To run the same file in parallel, you have to ask to run it more than once: "-j2 test_mailbox test_mailbox" or "-j2 test_mailbox -F" for example.

-F runs the same tests in a loop until it fails. It's a convenient way to run the same test in parallel to detect race conditions ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39029>
_______________________________________

From report at bugs.python.org  Thu Jan  9 07:05:40 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jan 2020 12:05:40 +0000
Subject: [issue39161] Py_NewInterpreter docs need updating for multi-phase
 initialization
In-Reply-To: <1577683127.59.0.69655210791.issue39161@roundup.psfhosted.org>
Message-ID: <1578571540.77.0.605853695211.issue39161@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6c5d661342d12f6836580b0e75e3569c764527ae by Miss Islington (bot) (Petr Viktorin) in branch 'master':
bpo-39161: Document multi-phase init modules under Py_NewInterpreter() (GH-17896)
https://github.com/python/cpython/commit/6c5d661342d12f6836580b0e75e3569c764527ae


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39161>
_______________________________________

From report at bugs.python.org  Thu Jan  9 07:05:40 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jan 2020 12:05:40 +0000
Subject: [issue39161] Py_NewInterpreter docs need updating for multi-phase
 initialization
In-Reply-To: <1577683127.59.0.69655210791.issue39161@roundup.psfhosted.org>
Message-ID: <1578571540.2.0.504982424289.issue39161@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17329
pull_request: https://github.com/python/cpython/pull/17918

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39161>
_______________________________________

From report at bugs.python.org  Thu Jan  9 07:27:42 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jan 2020 12:27:42 +0000
Subject: [issue39161] Py_NewInterpreter docs need updating for multi-phase
 initialization
In-Reply-To: <1577683127.59.0.69655210791.issue39161@roundup.psfhosted.org>
Message-ID: <1578572862.64.0.845528309871.issue39161@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 20c990229e98ad69c03e44fe61f8dce99b96cf9d by Miss Islington (bot) in branch '3.8':
bpo-39161: Document multi-phase init modules under Py_NewInterpreter() (GH-17896)
https://github.com/python/cpython/commit/20c990229e98ad69c03e44fe61f8dce99b96cf9d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39161>
_______________________________________

From report at bugs.python.org  Thu Jan  9 07:28:05 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 09 Jan 2020 12:28:05 +0000
Subject: [issue39161] Py_NewInterpreter docs need updating for multi-phase
 initialization
In-Reply-To: <1577683127.59.0.69655210791.issue39161@roundup.psfhosted.org>
Message-ID: <1578572885.25.0.984283645891.issue39161@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39161>
_______________________________________

From report at bugs.python.org  Thu Jan  9 07:33:02 2020
From: report at bugs.python.org (Gareth Rees)
Date: Thu, 09 Jan 2020 12:33:02 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1578573182.91.0.076924179128.issue17005@roundup.psfhosted.org>


Gareth Rees <gdr at garethrees.org> added the comment:

I'd like to push back on the idea that graphs with isolated vertices are "unusual cases" as suggested by Raymond.

A very common use case (possibly the most common) for topological sorting is job scheduling. In this use case you have a collection of jobs, some of which have dependencies on other jobs, and you want to output a schedule according to which the jobs can be executed so that each job is executed after all its dependencies.

In this use case, any job that has no dependencies, and is not itself a dependency of any other job, is an isolated vertex in the dependency graph. This means that the proposed interface (that is, the interface taking only pairs of vertices) will not be suitable for this use case. Any any programmer who tries to use it for this use case will be setting themselves up for failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Thu Jan  9 07:43:51 2020
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Durand?=)
Date: Thu, 09 Jan 2020 12:43:51 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
Message-ID: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>


New submission from Fran?ois Durand <fradurandpub at gmail.com>:

As of now, fractions.Fraction.__bool__ is implemented as: ``return a._numerator != 0``. However, this does not necessary return a bool (which would be desired). In particular, when the numerator is a numpy integer, this returns a numpy bool instead. Another solution would be to implement fractions.Fraction.__bool__ as: ``return bool(numerator)``. What do you think?

This message follows a thread here: https://github.com/numpy/numpy/issues/15277 .

----------
messages: 359673
nosy: francois-durand
priority: normal
severity: normal
status: open
title: Conversion from fractions.Fraction to bool
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/issue39274>
_______________________________________

From report at bugs.python.org  Thu Jan  9 07:45:17 2020
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois_Durand?=)
Date: Thu, 09 Jan 2020 12:45:17 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1578573917.71.0.0904997075632.issue39274@roundup.psfhosted.org>


Fran?ois Durand <fradurandpub at gmail.com> added the comment:

As of now, fractions.Fraction.__bool__ is implemented as: ``return a._numerator != 0``. However, this does not necessary return a bool (which would be desired). In particular, when the numerator is a numpy integer, this returns a numpy bool instead. Another solution would be to implement fractions.Fraction.__bool__ as: ``return bool(a._numerator)``. What do you think?

This message follows a thread here: https://github.com/numpy/numpy/issues/15277 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39274>
_______________________________________

From report at bugs.python.org  Thu Jan  9 08:02:19 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jan 2020 13:02:19 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1578574939.59.0.971092200947.issue39274@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +mark.dickinson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39274>
_______________________________________

From report at bugs.python.org  Thu Jan  9 08:14:20 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 09 Jan 2020 13:14:20 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1578575660.97.0.7909841678.issue39274@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Agreed that __bool__ should return an actual bool.
``return bool(a._numerator)`` does seem like the obvious way to do this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39274>
_______________________________________

From report at bugs.python.org  Thu Jan  9 08:22:17 2020
From: report at bugs.python.org (Matej Cepl)
Date: Thu, 09 Jan 2020 13:22:17 +0000
Subject: [issue37539] CheckCommitCursorReset regression sqlite3 test fails
 with old sqlite3
In-Reply-To: <1562744749.11.0.451053951717.issue37539@roundup.psfhosted.org>
Message-ID: <1578576137.82.0.221760417395.issue37539@roundup.psfhosted.org>


Matej Cepl <mcepl at cepl.eu> added the comment:

Fix for this situations (and we are talking about sqlite3 3.6.4, which is truly archaeological excavation) skip particular test.

----------
keywords: +patch
Added file: https://bugs.python.org/file48833/avoid-sqlite-race.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37539>
_______________________________________

From report at bugs.python.org  Thu Jan  9 08:25:31 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 09 Jan 2020 13:25:31 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1578576331.16.0.299460496516.issue39274@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For completeness and to save people going to the NumPy tracker, here's an example of the problem:

Python 3.8.1 (default, Jan  5 2020, 21:32:35) 
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import fractions, numpy
>>> f = fractions.Fraction(numpy.int64(1), 2)
>>> not f
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __bool__ should return bool, returned numpy.bool_

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39274>
_______________________________________

From report at bugs.python.org  Thu Jan  9 08:25:48 2020
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 09 Jan 2020 13:25:48 +0000
Subject: [issue39275] Traceback off by one line when
Message-ID: <1578576348.64.0.412986299263.issue39275@roundup.psfhosted.org>


New submission from Facundo Batista <facundo at taniquetil.com.ar>:

When using pdb to debug, the traceback is off by one line.

For example, this simple script:

```
print("line 1")
import pdb;pdb.set_trace()
print("line 2")
print("line 3", broken)
print("line 4")
```

...when run produces the following traceback (after hitting 'n' in pdb, of course):

```
Traceback (most recent call last):
  File "/home/facundo/foo.py", line 3, in <module>
    print("line 2")
NameError: name 'broken' is not defined
```

----------
messages: 359678
nosy: facundobatista
priority: normal
severity: normal
status: open
title: Traceback off by one line when
versions: Python 3.6, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39275>
_______________________________________

From report at bugs.python.org  Thu Jan  9 08:36:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 13:36:51 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1578577011.93.0.568897004694.issue39274@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> ``return bool(a._numerator)`` does seem like the obvious way to do this.

Yes, it's a good fix. It's used on other places.

--

numbers.Complex.__bool__() also uses "self != 0". Is it an issue?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39274>
_______________________________________

From report at bugs.python.org  Thu Jan  9 08:52:14 2020
From: report at bugs.python.org (=?utf-8?q?Pawe=C5=82_Karczewski?=)
Date: Thu, 09 Jan 2020 13:52:14 +0000
Subject: [issue39276] type() cause segmentation fault in callback function
 called from C extension
Message-ID: <1578577934.03.0.00618526975979.issue39276@roundup.psfhosted.org>


New submission from Pawe? Karczewski <pawel.karczewski at intel.com>:

How to reproduce:

1. Create callback function, which may take any object and run type() on it
  def builtin_type_in_callback(obj):
          type(obj)

2. Create C extension with two types defined in it - Internal and External. 
  Eternal type should implement method (let's name it Call), which can get callback function

		static PyObject *
		Call(ExternalObject *self, PyObject* args) {
		PyObject* python_callback;
		if (!PyArg_ParseTuple(args, "O:set_callback",  &python_callback)) {
			return NULL;
		}
		callback_runner(python_callback);
		if(PyErr_Occurred() != NULL)
			return NULL;
		Py_RETURN_NONE;
		}  
  Inside this function create object of Internal type and pass it to callback function
	void callback_runner(void* callback_function)  {
		InternalObject *entry = PyObject_New(InternalObject, &InternalType);
		PyObject_Init((PyObject*)entry, &InternalType);
		PyObject *args = PyTuple_New(1);
		if (args != NULL) {
			if (PyTuple_SetItem(args, 0, (PyObject *)entry) == 0) {
				PyObject *res = PyObject_CallObject((PyObject *) callback_function, args);
				Py_XDECREF(res);
			}
		}
		
When type() is called on object of Internal type segmentation fault occur. However, if dir() was called
on such object before type(), type() works properly and returns type of Internal Object.

For more details please look into reproducer code.

----------
components: C API
files: cpython_type_segfaulter.tgz
messages: 359680
nosy: karczex
priority: normal
severity: normal
status: open
title: type() cause segmentation fault  in callback function called from C extension
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48834/cpython_type_segfaulter.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39276>
_______________________________________

From report at bugs.python.org  Thu Jan  9 09:02:46 2020
From: report at bugs.python.org (Sebastian Berg)
Date: Thu, 09 Jan 2020 14:02:46 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1578578566.46.0.282664832047.issue39274@roundup.psfhosted.org>


Sebastian Berg <sebastian at sipsolutions.net> added the comment:

Thanks for the quick responses.

@Victor Stinner, I suppose you could change `numbers.Complex.__bool__()` by adding the no-op bool to make it: `bool(self != 0)`.

But I am not sure I feel it is necessary. NumPy is a bit a strange in that it uses its own boolean scalar, and it is easy to override the slot for such objects.

----------
nosy: +seberg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39274>
_______________________________________

From report at bugs.python.org  Thu Jan  9 09:43:45 2020
From: report at bugs.python.org (Thomas Grainger)
Date: Thu, 09 Jan 2020 14:43:45 +0000
Subject: [issue39277] _PyTime_FromDouble() fails to detect an integer overflow
 when converting a C double to a C int64_t
Message-ID: <1578581025.66.0.18478821427.issue39277@roundup.psfhosted.org>


New submission from Thomas Grainger <tagrain at gmail.com>:

_PyTime_FromDouble() fails to detect an integer overflow when converting a C double to a C int64_t

Python 3.7.5 (default, Nov 20 2019, 09:21:52) 
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.sleep(9223372036.854777)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: sleep length must be non-negative

----------
messages: 359682
nosy: graingert, vstinner
priority: normal
severity: normal
status: open
title: _PyTime_FromDouble() fails to detect an integer overflow when converting a C double to a C int64_t
type: behavior
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39277>
_______________________________________

From report at bugs.python.org  Thu Jan  9 09:52:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 09 Jan 2020 14:52:07 +0000
Subject: [issue39277] _PyTime_FromDouble() fails to detect an integer overflow
 when converting a C double to a C int64_t
In-Reply-To: <1578581025.66.0.18478821427.issue39277@roundup.psfhosted.org>
Message-ID: <1578581527.5.0.932903594264.issue39277@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It's a bug in _PyTime_FromDouble() which fails to detect the integer overflow when casting a C double to a C _PyTime_T (int64_t): bug in _Py_InIntegralTypeRange(_PyTime_t, d) where d is a C double.

On my Fedora 31, double is a 64-bit IEEE 754 float, _PyTime_t is int64_t (64-bit signed integer).

_PyTime_t maximum is 9223372036854775807. But casted as C double, it becomes 9223372036854775808:

>>> int(float(9223372036854775807))
9223372036854775808

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39277>
_______________________________________

From report at bugs.python.org  Thu Jan  9 10:02:52 2020
From: report at bugs.python.org (Thomas Grainger)
Date: Thu, 09 Jan 2020 15:02:52 +0000
Subject: [issue39277] _PyTime_FromDouble() fails to detect an integer overflow
 when converting a C double to a C int64_t
In-Reply-To: <1578581025.66.0.18478821427.issue39277@roundup.psfhosted.org>
Message-ID: <1578582172.14.0.192541062435.issue39277@roundup.psfhosted.org>


Change by Thomas Grainger <tagrain at gmail.com>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39277>
_______________________________________

From report at bugs.python.org  Thu Jan  9 10:09:29 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 09 Jan 2020 15:09:29 +0000
Subject: [issue39150] See if PyToken_OneChar would be faster as a lookup table
In-Reply-To: <1577583921.53.0.126418549221.issue39150@roundup.psfhosted.org>
Message-ID: <1578582569.04.0.422842821217.issue39150@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

Yes, I ran it multiple times on my 2013 Macbook Pro and got ~10% speedup.  I also ran it on my Linux VM (that I only use for development) and got a speedup but less so.

The code I used to run the tests is at: https://github.com/petdance/cpython/blob/Issue39150/timetests

LOG=timelog.txt
NRUNS=100
NFILES=100

if [ -x ./python.exe ] ; then
    PYTHON=./python.exe
else
    PYTHON=./python
fi

# Build a file list, but throw out some that have syntax errors.
# Use the 100 biggest files.
FILES=$(
    find . -name '*.py' -type f -ls \
    | grep -v Tools/test2to3/ \
    | grep -v Lib/lib2to3/tests/ \
    | grep -v Lib/test/badsyntax \
    | grep -v Lib/test/bad_coding \
    | sort -r -n -k7 \
    | awk '{print $11}' \
    | head -n $NFILES
)

echo "Compiling $NFILES files for $NRUNS iterations"

rm -f $LOG

for (( i=1; i<=$NRUNS; i++ )) do
    echo "Run $i"
    { time $PYTHON -m py_compile $FILES; } >> $LOG 2>&1
done

perl -ne'if(/real\s+0m([\d.]+)s/){$t+=$1;$n++} END { printf "%d runs, average %0.4f\n", $n, $t/$n}' $LOG

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39150>
_______________________________________

From report at bugs.python.org  Thu Jan  9 10:16:43 2020
From: report at bugs.python.org (Andy Lester)
Date: Thu, 09 Jan 2020 15:16:43 +0000
Subject: [issue39150] See if PyToken_OneChar would be faster as a lookup table
In-Reply-To: <1577583921.53.0.126418549221.issue39150@roundup.psfhosted.org>
Message-ID: <1578583003.68.0.383738702633.issue39150@roundup.psfhosted.org>


Andy Lester <andy at petdance.com> added the comment:

Re: branch prediction.

The branch

    if (c1>=37 && c1<=126)

could just as easily be

    if (c1>=0 && c1<=126)

with no other changes to the code.  It could be just

    if (c1<=126)

if c1 wasn't signed.

As far as branch prediction, we could make it something like

    if (c1>=0 && c1<=255)

and expand the table lookup, depending on what the likely inputs are.  I could play around with that some if anyone was interested.

I'm not trying to push on this.  Just sharing some thoughts and research.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39150>
_______________________________________

From report at bugs.python.org  Thu Jan  9 10:59:06 2020
From: report at bugs.python.org (Julien Palard)
Date: Thu, 09 Jan 2020 15:59:06 +0000
Subject: [issue1681671] Python and Indeterminate Forms (Math)
Message-ID: <1578585545.99.0.638932692338.issue1681671@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1681671>
_______________________________________

From report at bugs.python.org  Thu Jan  9 12:00:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 09 Jan 2020 17:00:47 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1578589247.31.0.761523386452.issue25172@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset ed367815eeb9329c48a86a8a7fa3186e27a10f2c by Steve Dower in branch 'master':
bpo-25172: Reduce scope of crypt import tests (GH-17881)
https://github.com/python/cpython/commit/ed367815eeb9329c48a86a8a7fa3186e27a10f2c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Thu Jan  9 12:01:06 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jan 2020 17:01:06 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1578589266.46.0.463125794645.issue25172@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17330
pull_request: https://github.com/python/cpython/pull/17922

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Thu Jan  9 12:10:01 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 09 Jan 2020 17:10:01 +0000
Subject: [issue39276] type() cause segmentation fault in callback function
 called from C extension
In-Reply-To: <1578577934.03.0.00618526975979.issue39276@roundup.psfhosted.org>
Message-ID: <1578589801.75.0.87246348389.issue39276@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

static PyTypeObject InternalType should have

PyVarObject_HEAD_INIT(&PyType_Type, 0) 

instead of

PyVarObject_HEAD_INIT(NULL, 0)

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39276>
_______________________________________

From report at bugs.python.org  Thu Jan  9 12:13:03 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 09 Jan 2020 17:13:03 +0000
Subject: [issue39276] type() cause segmentation fault in callback function
 called from C extension
In-Reply-To: <1578577934.03.0.00618526975979.issue39276@roundup.psfhosted.org>
Message-ID: <1578589983.59.0.620418766827.issue39276@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg359687

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39276>
_______________________________________

From report at bugs.python.org  Thu Jan  9 12:20:06 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jan 2020 17:20:06 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1578590406.63.0.774967641057.issue25172@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8c08518c255747a06d00479f21087f0c934d0ad6 by Miss Islington (bot) in branch '3.8':
bpo-25172: Reduce scope of crypt import tests (GH-17881)
https://github.com/python/cpython/commit/8c08518c255747a06d00479f21087f0c934d0ad6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Thu Jan  9 12:37:23 2020
From: report at bugs.python.org (Carl Bordum Hansen)
Date: Thu, 09 Jan 2020 17:37:23 +0000
Subject: [issue39278] add docstrings to functions in pdb module
Message-ID: <1578591443.64.0.597501227111.issue39278@roundup.psfhosted.org>


New submission from Carl Bordum Hansen <carl at bordum.dk>:

The functions are documented, but not in doc strings which means you cannot call help() on them.

>From this twitter thread: https://twitter.com/raymondh/status/1211414561468952577

----------
assignee: docs at python
components: Documentation
messages: 359689
nosy: carlbordum, docs at python
priority: normal
severity: normal
status: open
title: add docstrings to functions in pdb module
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39278>
_______________________________________

From report at bugs.python.org  Thu Jan  9 12:40:12 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 09 Jan 2020 17:40:12 +0000
Subject: [issue25172] Unix-only crypt should not be present on Windows.
In-Reply-To: <1442623771.44.0.313946014303.issue25172@psf.upfronthosting.co.za>
Message-ID: <1578591612.8.0.450606256569.issue25172@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25172>
_______________________________________

From report at bugs.python.org  Thu Jan  9 12:41:50 2020
From: report at bugs.python.org (Carl Bordum Hansen)
Date: Thu, 09 Jan 2020 17:41:50 +0000
Subject: [issue39278] add docstrings to functions in pdb module
In-Reply-To: <1578591443.64.0.597501227111.issue39278@roundup.psfhosted.org>
Message-ID: <1578591710.77.0.40865906583.issue39278@roundup.psfhosted.org>


Change by Carl Bordum Hansen <carl at bordum.dk>:


----------
keywords: +patch
pull_requests: +17331
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17924

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39278>
_______________________________________

From report at bugs.python.org  Thu Jan  9 12:42:12 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 09 Jan 2020 17:42:12 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
In-Reply-To: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>
Message-ID: <1578591732.21.0.428202486068.issue39235@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

OK, so I looked into this (sine we can't wait for Serhiy).

The problem was probably introduced when Ivan added end lineno/column attributes to parse tree nodes. The offending copy_location() call copies the begin and end locations from the given node (maybegenbeg). But in the problematic case, maybegenbeg is just the left paren in the function call, not the node representing the surrounding () group.

But there's a separate argument to ast_for_call(), closepar, that should be used for the end lineno/offset.

Looking at the various calls to ast_for_call() in Python/ast.c, we find these:

- ast_for_decorator -- passes the open and close parentheses- ast_for_trailer -- passes the open and close parentheses
- ast_for_classdef -- passes NULL (because no genexpr allowed here)

So instead of calling copy_location() we should manually set the begin and end positions.

An alternative would be to add a second node* argument to copy_location(). That would require us to modify all 5 calls to it, but it still feels the better way to go. I'll see if I can produce a PR for that.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39235>
_______________________________________

From report at bugs.python.org  Thu Jan  9 12:55:55 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 09 Jan 2020 17:55:55 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
In-Reply-To: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>
Message-ID: <1578592555.86.0.268867991772.issue39235@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
keywords: +patch
pull_requests: +17332
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17925

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39235>
_______________________________________

From report at bugs.python.org  Thu Jan  9 13:40:36 2020
From: report at bugs.python.org (Josh Lee)
Date: Thu, 09 Jan 2020 18:40:36 +0000
Subject: [issue26495] super() does not work in nested functions, genexps,
 listcomps, and gives misleading exceptions
In-Reply-To: <1457290649.73.0.734693015263.issue26495@psf.upfronthosting.co.za>
Message-ID: <1578595236.68.0.241212660669.issue26495@roundup.psfhosted.org>


Change by Josh Lee <jleedev at gmail.com>:


----------
nosy: +jleedev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26495>
_______________________________________

From report at bugs.python.org  Thu Jan  9 13:52:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 09 Jan 2020 18:52:36 +0000
Subject: [issue39275] Traceback off by one line when
In-Reply-To: <1578576348.64.0.412986299263.issue39275@roundup.psfhosted.org>
Message-ID: <1578595956.59.0.761741889968.issue39275@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This looks similar to issue35405 . See also issue16482 with a patch.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39275>
_______________________________________

From report at bugs.python.org  Thu Jan  9 14:03:37 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 09 Jan 2020 19:03:37 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
In-Reply-To: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>
Message-ID: <1578596617.36.0.584675098857.issue39235@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +17333
pull_request: https://github.com/python/cpython/pull/17926

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39235>
_______________________________________

From report at bugs.python.org  Thu Jan  9 14:18:54 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jan 2020 19:18:54 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
In-Reply-To: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>
Message-ID: <1578597534.48.0.480636334898.issue39235@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a796d8ef9dd1af65f7e4d7a857b56f35b7cb6e78 by Miss Islington (bot) (Guido van Rossum) in branch 'master':
bpo-39235: Fix end location for genexp in call args (GH-17925)
https://github.com/python/cpython/commit/a796d8ef9dd1af65f7e4d7a857b56f35b7cb6e78


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39235>
_______________________________________

From report at bugs.python.org  Thu Jan  9 14:19:02 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jan 2020 19:19:02 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
In-Reply-To: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>
Message-ID: <1578597542.19.0.413407726415.issue39235@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17334
pull_request: https://github.com/python/cpython/pull/17927

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39235>
_______________________________________

From report at bugs.python.org  Thu Jan  9 14:39:09 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 09 Jan 2020 19:39:09 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
In-Reply-To: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>
Message-ID: <1578598749.95.0.0989017698537.issue39235@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 33e033da3c1472b0aa2ae3cff06649a1ae4aa37f by Miss Islington (bot) in branch '3.8':
bpo-39235: Fix end location for genexp in call args (GH-17925)
https://github.com/python/cpython/commit/33e033da3c1472b0aa2ae3cff06649a1ae4aa37f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39235>
_______________________________________

From report at bugs.python.org  Thu Jan  9 16:02:11 2020
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 09 Jan 2020 21:02:11 +0000
Subject: [issue39279] Don't allow non-Ascii digits in platform.py
Message-ID: <1578603731.26.0.701759063569.issue39279@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

The platform.py module takes non-Ascii digits in regexes in places it shouldn't. e.g. digits like ? and ? and accepted, when only the Ascii digits between 0-9 should be accepted.

----------
components: Library (Lib)
messages: 359694
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Don't allow non-Ascii digits in platform.py
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39279>
_______________________________________

From report at bugs.python.org  Thu Jan  9 16:05:51 2020
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 09 Jan 2020 21:05:51 +0000
Subject: [issue39279] Don't allow non-Ascii digits in platform.py
In-Reply-To: <1578603731.26.0.701759063569.issue39279@roundup.psfhosted.org>
Message-ID: <1578603951.8.0.619613443336.issue39279@roundup.psfhosted.org>


Change by Ram Rachum <ram at rachum.com>:


----------
keywords: +patch
pull_requests: +17335
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17928

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39279>
_______________________________________

From report at bugs.python.org  Thu Jan  9 16:10:55 2020
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 09 Jan 2020 21:10:55 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
Message-ID: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>


New submission from Ram Rachum <ram at rachum.com>:

I've been doing some research into the use of `\d` in regular expressions in CPython, and any security vulnerabilities that might happen as a result of the fact that it accepts non-Ascii digits like ? and ?.

In most places in the CPython codebase, the `re.ASCII` flag is used for such cases, thus ensuring the `re` module prohibits these non-Ascii digits. Personally, my preference is to never use `\d` and always use `[0-9]`. I think that it's rule that's more easy to enforce and less likely to result in a slipup, but that's a matter of personal taste.

I found a few places where we don't use the `re.ASCII` flag and we do accept non-Ascii digits.

The first and less interesting place is platform.py, where we define patterns used for detecting versions of PyPy and IronPython. I don't know how anyone would exploit that, but personally I'd change that to a [0-9] just to be safe. I've opened bpo-39279 for that. 

The more sensitive place is the `datetime` module. 

Happily, the `datetime.datetime.fromisoformat` function rejects non-Ascii digits. But the `datetime.datetime.strptime` function does not: 

    from datetime import datetime
    
    time_format = '%Y-%m-%d'
    parse = lambda s: datetime.strptime(s, time_format)
       
    x = '?019-12-22'
    y = '2019-12-22'
    assert x != y
    assert parse(x) == parse(y)
    print(parse(x))
    # Output: 2019-12-22 00:00:00

If user code were to check for uniqueness of a datetime by comparing it as a string, this is where an attacker could fool this logic, by using a non-Ascii digit.

Two more interesting points about this: 

1. If you'd try the same trick, but you'd insert ? in the day section instead of the year section, Python would reject that. So we definitely have inconsistent behavior.
2. In the documentation for `strptime`, we're referencing the 1989 C standard. Since the first version of Unicode was published in 1991, it's reasonable not to expect the standard to support digits that were introduced in Unicode.

If you'd scroll down in that documentation, you'll see that we also implement the less-known ISO 8601 standard, where `%G-%V-%u` represents a year, week number, and day of week. The `%G` is vulnerable:
    
    from datetime import datetime
    
    time_format = '%G-%V-%u'
    parse = lambda s: datetime.strptime(s, time_format)
   
    x = '?019-53-4'
    y = '2019-53-4'
    assert x != y
    assert parse(x) == parse(y)
    print(parse(x))
    # Output: 2020-01-02 00:00:00

I looked at the ISO 8601:2004 document, and under the "Fundamental principles" chapter, it says:

    This International Standard gives a set of rules for the representation of
        time points
        time intervals
        recurring time intervals.
        Both accurate and approximate representations can be identified by means of unique and unambiguous expressions specifying the relevant dates, times of day and durations.  

Note the "unique and unambiguous". By accepting non-Ascii digits, we're breaking the uniqueness requirement of ISO 8601.

----------
components: Library (Lib)
messages: 359695
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Don't allow datetime parsing to accept non-Ascii digits
type: security
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Thu Jan  9 17:02:25 2020
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 09 Jan 2020 22:02:25 +0000
Subject: [issue39279] Don't allow non-Ascii digits in platform.py
In-Reply-To: <1578603731.26.0.701759063569.issue39279@roundup.psfhosted.org>
Message-ID: <1578607345.83.0.742344656499.issue39279@roundup.psfhosted.org>


Change by Ram Rachum <ram at rachum.com>:


----------
pull_requests: +17336
pull_request: https://github.com/python/cpython/pull/17931

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39279>
_______________________________________

From report at bugs.python.org  Thu Jan  9 17:14:59 2020
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 09 Jan 2020 22:14:59 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>
Message-ID: <1578608098.99.0.245953041487.issue39280@roundup.psfhosted.org>


Change by Ram Rachum <ram at rachum.com>:


----------
keywords: +patch
pull_requests: +17337
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17931

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Thu Jan  9 17:36:38 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 09 Jan 2020 22:36:38 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>
Message-ID: <1578609398.15.0.316165218675.issue39280@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I don't love the inconsistency, but can you elaborate on the actual *danger* posed by this? What security vulnerabilities involve parsing a datetime using a non-ascii digit?

The reason that `fromisoformat` doesn't accept non-ASCII digits is actually because it's the inverse of `datetime.isoformat`, which never *emits* non-ASCII digits. For `strptime`, we're really going more for a general specifier for parsing datetime strings in a given format. I'll note that we do accept any valid unicode character for the date/time separator.

>From my perspective, there are a few goals, some of which may be in conflict with the others:

1. Mitigating security vulnerabilities, if they exist.
2. Supporting international locales if possible.
3. Improving consistency in the API.

If no one ever actually specifies datetimes in non-ascii locales (and this gravestone that includes the date in both Latin and Chinese/Japanese characters seems to suggest otherwise: https://jbnewall.com/wp-content/uploads/2017/02/LEE-MONUMENT1-370x270.jpg ), then I don't see a problem dropping our patchy support, but I think we need to carefully consider the backwards compatibility implications if we go through with that.

One bit of evidence in favor of "no one uses this anyway" is that no one has yet complained that apparently this doesn't work for "%d" even if it works for "%y", so presumably it's not heavily used. If our support for this sort of thing is so broken that no one could possibly be using it, I suppose we may as well break it all the way, but it would be nice to try and identify some resources that the documentation can point to for how to handle international date parsing.


> Note the "unique and unambiguous". By accepting non-Ascii digits, we're breaking the uniqueness requirement of ISO 8601.

I think in this case "but the standard says X" is probably not a very strong argument. 
 Even if we were coding to the ISO 8601 standard (I don't think we claim to be, we're just using that convention), I don't really know how to interpret the "unique" portion of that claim, considering that ISO 8601 specifies dozens of ways to represent the same datetime. Here's an example from [my `dateutil.parse.isoparse` test suite](https://github.com/dateutil/dateutil/blob/110a09b4ad46fb87ae858a14bfb5a6b92557b01d/dateutil/test/test_isoparser.py#L150):

```
    '2014-04-11T00',
    '2014-04-10T24',
    '2014-04-11T00:00',
    '2014-04-10T24:00',
    '2014-04-11T00:00:00',
    '2014-04-10T24:00:00',
    '2014-04-11T00:00:00.000',
    '2014-04-10T24:00:00.000',
    '2014-04-11T00:00:00.000000',
    '2014-04-10T24:00:00.000000'
```

All of these represent the exact same moment in time, and this doesn't even get into using the week-number/day-number configurations or anything with time zones. They also allow for the use of `,` as the subsecond-component separator (so add 4 more variants for that) and they allow you to leave out the dashes between the date components and the colons between time components, so you can multiply the possible variants by 4.

Just a random aside - I think there may be strong arguments for doing this even if we don't care about coding to a specific standard.

----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Thu Jan  9 17:38:43 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 09 Jan 2020 22:38:43 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>
Message-ID: <1578609523.24.0.0880866082178.issue39280@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> If user code were to check for uniqueness of a datetime by comparing it as a string, this is where an attacker could fool this logic, by using a non-Ascii digit.

To me, this seems like a pretty thin justification for calling this a security vulnerability.

Using the exact same reasoning, one could argue that "If user code were to check for uniqueness of a float by comparing it as a string, this is where an attacker could fool this logic, by using leading or trailing spaces, extra non-significant digits, upper- or lowercase 'E', etc."

py> float(" +00012.145000000000000099999e00 ") == float("12.145")
True

Referring specifically to strptime(), there are many format codes which break uniqueness by allowing optional leading zeroes, and month names are case insensitive e.g. %b accepts 'jAn' as well as 'Jan'.

https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior

As far as the inconsistency, I think that's an argument for being less strict, not more, and allowing non-ASCII digits in more places not just the first. Why shouldn't (let's say) a Bengali user specify the day of the month using Bengali digits?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Thu Jan  9 18:00:24 2020
From: report at bugs.python.org (Ram Rachum)
Date: Thu, 09 Jan 2020 23:00:24 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>
Message-ID: <1578610824.68.0.415001022151.issue39280@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

> To me, this seems like a pretty thin justification for calling this a security vulnerability.

I know that lots of exploits were made because of bugs in Python's URL parsing, and security releases of Python were made because of that. It's possible that similar exploits could be done for bugs in parsing datetimes. It's different, and it's a thin justification, I agree, so if it's treated as a non-security bug, I'm okay with that. 


> ISO 8601 specifies dozens of ways to represent the same datetime

Yes, but not within the same format. If someone were to choose the format '2014-04-10T24:00:00', they would have a reasonable expectation that there is only one unique string that corresponds with that datetime.

> As far as the inconsistency, I think that's an argument for being less strict, not more, and allowing non-ASCII digits in more places not just the first. Why shouldn't (let's say) a Bengali user specify the day of the month using Bengali digits?

That's an interesting direction. It might be a good thing to allow users in different locales to specify datetime with their native digits. But, if we were to go in that direction, we would have to: 

1. Define that use case more rigorously, consider whether it has any effects we need to consider, like clashes with how the local culture expresses dates. Maybe we accept the year 2020 in Elbonian digits, but the Elbonian people count their years from the birth of Saint Elbon, and for them the year 2020 in Elbonian digits means -1553 BC for us?
2. Enable it in other fields except year.
3. Add tests for it. 

Since we're not going to do that ever, I don't think there's a point in leaving a 10% implementation of non-Ascii datetime parsing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Thu Jan  9 19:52:37 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 10 Jan 2020 00:52:37 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1578617557.48.0.0171578185236.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> For a struct-specific getter we usually end the prefix with an
underscore: _PyInterpreter_IsFinalizing.  Otherwise, that's the same
name I would have used. :)

Good to know, thanks!

> No worries (or hurries).  Just request a review from me when you're
ready.  Thanks again for working on this!

No problem, and thanks for your continued patience. I've been a bit additionally busy recently with the holidays and preparing for an upcoming technical interview w/ Amazon, so I didn't have time to thoroughly test my proposed fix. This would potentially be my first full-time job in the Software Engineering industry. As a result, I have a lot to prepare for.

When I get the chance to open a PR after ensuring it at least 100% fixes the failure I was targeting, I'll be sure to add you as a reviewer. 

If any deadline comes up for this, feel free to move forward with implementing any part of my suggestions (or an entirely different fix that resolves the other failures at the same time). I should have time to work on this in the near future though.

Thanks again for the guidance and patience with this! I've learned a lot about the C-API and C in general (which has been a weaker area for me) from my time spent working on the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Thu Jan  9 20:26:34 2020
From: report at bugs.python.org (Dan Snider)
Date: Fri, 10 Jan 2020 01:26:34 +0000
Subject: [issue39281] The CO_NESTED flag is associated with a significant
 performance cost
Message-ID: <1578619594.45.0.842825761348.issue39281@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

The title was carefully worded as I have no idea how or why what is happening is happening, only that it has been like this since a least 3.6.0. That version in particular, by the way, is able to execute a call to a python function with 1 argument 25% faster than 3.8.0 but that may be due at least in part by whatever it is that makes it much faster to a call a unary function wrapped by functools.partial by utilizing the subcript operator on an instance of a partial subtype whose __getitem__ has been set to the data descriptor partial.func... Eg:

    class Party(partial): __getitem__ = partial.func
    fast = Party(hash)
    slow = partial(hash)

    # the expression `fast[""]` runs approximately 28% faster than
    # the expression `slow("")`, and partial.func as __getitem__ is
    # confusingly 139% faster than partial.__call__...

That rather large digression aside, here's a demonstration of two functions identical in every way except the CO_NESTED bit and perhaps the names:

if 1:
    def Slow():
        global Slow
        class  Slow:
            global slow
            def slow(self): return self
        return Slow
    if  Slow():
        class Fast:
            global fast
            def fast(self): return self
    import dis
    dis.show_code(slow)
    print()
    dis.show_code(fast)

----------
messages: 359700
nosy: bup
priority: normal
severity: normal
status: open
title: The CO_NESTED flag is associated with a significant performance cost
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39281>
_______________________________________

From report at bugs.python.org  Thu Jan  9 20:29:16 2020
From: report at bugs.python.org (Milo D Kerr)
Date: Fri, 10 Jan 2020 01:29:16 +0000
Subject: [issue22213] Make pyvenv style virtual environments easier to
 configure when embedding Python
In-Reply-To: <1408275761.36.0.915361061447.issue22213@psf.upfronthosting.co.za>
Message-ID: <1578619756.13.0.724703777865.issue22213@roundup.psfhosted.org>


Change by Milo D Kerr <dyamikerr at gmail.com>:


----------
nosy: +M.Kerr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22213>
_______________________________________

From report at bugs.python.org  Thu Jan  9 20:44:21 2020
From: report at bugs.python.org (Milo D Kerr)
Date: Fri, 10 Jan 2020 01:44:21 +0000
Subject: [issue39282] python-config --embed documentation
Message-ID: <1578620661.54.0.572519425656.issue39282@roundup.psfhosted.org>


New submission from Milo D Kerr <dyamikerr at gmail.com>:

Update 3.8 embedding documentation to reflect changes in <a href='https://github.com/python/cpython/pull/13500'>PR 13500</a>
<a href='https://bugs.python.org/issue36721'>bpo 36721</a>

----------
messages: 359701
nosy: M.Kerr
priority: normal
severity: normal
status: open
title: python-config --embed documentation
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39282>
_______________________________________

From report at bugs.python.org  Thu Jan  9 20:48:46 2020
From: report at bugs.python.org (Milo D Kerr)
Date: Fri, 10 Jan 2020 01:48:46 +0000
Subject: [issue39282] python-config --embed documentation
In-Reply-To: <1578620661.54.0.572519425656.issue39282@roundup.psfhosted.org>
Message-ID: <1578620926.35.0.658014645276.issue39282@roundup.psfhosted.org>


Change by Milo D Kerr <dyamikerr at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39282>
_______________________________________

From report at bugs.python.org  Thu Jan  9 21:24:43 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 10 Jan 2020 02:24:43 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1578623083.29.0.958363917748.issue17005@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Let's stir this up a bit ;-)  I recently had occasion to exchange ideas with Larry Hastings about topsorts for use in a package manager he's writing.  I thought his API for adding edges was ... perfect:

    add(node, *dependson)

So, e.g., add(A, B, C) says A depends on B, and on C, but says nothing else about B and C.  This is almost always the way topsorts show up in real life:  you know what a thing depends *on* directly, but have scant idea how things may be in the opposite direction.  For example, you know that baking a cake requires (among other things) flour, but have no real idea of the universe of other things that require flour.  Likewise Larry knows which packages each package requires, but not the reverse.  Etc.

Nodes with no edges are trivial to add then:  add(A).

If you're building input to a topsort from a graph, also trivial:

    for n, p in node2predecessors.items():
        topsort_instance.add(n, *p)

and it doesn't matter whether the predecessors in the original graph were stored in a list, set, tuple, or any other iterable container.  Nothing special about an empty collection of predecessors either.

The other big thing that came up is that most topsort programs were useless for his goal:  downloading and installing packages takes significant wall clock time, and there's huge opportunity for exploiting parallelism.  But a flat sequence in topsort order gives no clue about what _can_ be done in parallel.  Instead you really want several methods, like

    prepare()

to say that you're done building the graph; and,

    get_ready()

to get all nodes ready to go, which haven't already been returned by get_ready() calls (initially, this is the collection of nodes with no predecessors, which prepare() can know); and,

    done(node)

to say that `node` (returned by a previous call to get_ready()) is finished now, so that the next call to get_ready() can return all (if any) nodes for which `node` was the last non-done predecessor; and,

    is_active()

to say whether the topsort can make more progress (is_active() returns True iff there are still nodes ready to go that haven't yet been passed out by get_ready(), or if the number of nodes marked done() is less than the number that have been passed out by get_ready()).

These are all easy to code, and allow the user to extract all the opportunities for parallelism that theoretically exist.  There is no static order that can do so, since the opportunities that exist at any time depend on the times and order in which nodes are marked done() in real life - and that may vary from one run to the next.

Of course a deterministic static order can be derived from those, like, e.g.,

    def static_order(self):
        self.prepare()
        while self.is_active():
            for node in self.get_ready():
                yield node
                self.done(node)

For parallel use, e.g.,

    self.prepare()
    while instance.is_active():
        for node in instance.get_ready():
            inq.put(node)
        node = outq.get()
        instance.done(node)

where worker threads or processes take nodes to work on off of queue `inq`, then, when the work for a node is done, put the node on queue `outq`.

Am I seriously suggesting this for Python?  Sure.  It's fun to advance the practical state of the art :-)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Thu Jan  9 21:37:05 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 10 Jan 2020 02:37:05 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1578623825.83.0.364513312767.issue17005@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Thu Jan  9 21:38:58 2020
From: report at bugs.python.org (Derek Frombach)
Date: Fri, 10 Jan 2020 02:38:58 +0000
Subject: [issue38973] Shared Memory List Returns 0 Length
In-Reply-To: <1575484189.99.0.873814899855.issue38973@roundup.psfhosted.org>
Message-ID: <1578623938.61.0.585099404645.issue38973@roundup.psfhosted.org>


Derek Frombach <neoredstone at gmail.com> added the comment:

Documentation on Global Descriptor Lock needs re-writing.  Found documentation in version 2, much more helpful.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38973>
_______________________________________

From report at bugs.python.org  Thu Jan  9 23:32:18 2020
From: report at bugs.python.org (Ajay Tripathi)
Date: Fri, 10 Jan 2020 04:32:18 +0000
Subject: [issue39283] Add ability to inherit unittest arguement parser
Message-ID: <1578630738.78.0.369523186494.issue39283@roundup.psfhosted.org>


New submission from Ajay Tripathi <ajay39in at gmail.com>:

I am currently writing a unittest script that requires argparser but since the unittest module already has a ArgumentParser instance, I cannot create and use my own ArgumentParser instance.


Possible solution:

The problem would be solved I could inherit the parent ArgumentParser instance created here:
https://github.com/python/cpython/blob/master/Lib/unittest/main.py#L162

Please let me know if it's feasible / acceptable to change `parent_parser` as `self.parent_parent` for inheritance.

I would love to create a pull request for it.

----------
components: Library (Lib)
messages: 359704
nosy: atb00ker
priority: normal
severity: normal
status: open
title: Add ability to inherit unittest arguement parser
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39283>
_______________________________________

From report at bugs.python.org  Fri Jan 10 01:44:02 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 10 Jan 2020 06:44:02 +0000
Subject: [issue34311] locale.format() and locale.format_string() cast Decimals
 to float
In-Reply-To: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za>
Message-ID: <1578638642.18.0.960815661853.issue34311@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Does the name "locale.localize" have some origin?

I feel the name doesn't represent well about it is for formatting numeric based on LC_NUMERIC.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34311>
_______________________________________

From report at bugs.python.org  Fri Jan 10 02:12:11 2020
From: report at bugs.python.org (printerhelp center)
Date: Fri, 10 Jan 2020 07:12:11 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1578640331.23.0.204850060671.issue32545@roundup.psfhosted.org>


printerhelp center <printerhelpcenter9 at gmail.com> added the comment:

As of late, numerous clients have griped concerning the sibling printer disconnected issue as it goes detached naturally or after some idle time which ranges from 10 to 30 minutes. This issue makes inconvenience as clients are not ready to print pages because the Printer itself will be recorded as disconnected. Furthermore, when you coordinated to write at precisely that point, the reports will be added to the line. Brother printer offline problem was held because of many explanations which are referenced underneath. To realize the statement in regards to that, please guarantee you will peruse the post totally without getting away from any means.

https://printerhelpcenter.com/how-to-fix-canon-printer-error-b200/
https://printerhelpcenter.com/fix-brother-printer-offline-to-online/

----------
nosy: +printerhelpcenter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Fri Jan 10 02:39:22 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 10 Jan 2020 07:39:22 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1578641962.84.0.704735747573.issue32545@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg359706

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Fri Jan 10 02:58:47 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 10 Jan 2020 07:58:47 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578610824.68.0.415001022151.issue39280@roundup.psfhosted.org>
Message-ID: <20200110075839.GG839@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> > ISO 8601 specifies dozens of ways to represent the same datetime
> 
> Yes, but not within the same format. If someone were to choose the 
> format '2014-04-10T24:00:00', they would have a reasonable expectation 
> that there is only one unique string that corresponds with that 
> datetime.

There are no format code in '2014-04-10T24:00:00', it cannot be a 
format. Without knowing the format, there is no way of telling what that 
string represents or whether it is a unique representation.

- Is the leading 0 in '04' mandatory or optional?
- Could the '00's be replaced by '0' or even left out altogether?
- Is 24:00:00 the exact same time as 00:00:00?
- If the final '00' represents seconds, does it accept microseconds '.000'?

> > As far as the inconsistency, I think that's an argument for being 
> > less strict, not more, and allowing non-ASCII digits in more places 
> > not just the first. Why shouldn't (let's say) a Bengali user specify 
> > the day of the month using Bengali digits?
> 
> That's an interesting direction. It might be a good thing to allow 
> users in different locales to specify datetime with their native 
> digits. But, if we were to go in that direction, we would have to:
> 
> 1. Define that use case more rigorously, consider whether it has any 
> effects we need to consider, like clashes with how the local culture 
> expresses dates.

I don't think so. Supporting different calendars is a seperate, and far 
more complex issue, than just supporting dumb transliteration of 
Hindu-Arabic digits 0...9 into other character sets.

This makes datetime behave more like int(), float(), etc, all of which 
accept non-ASCII digits including (e.g.) East-Asian double-width digits.

    py> int('????')
    5432

Supporting non-Western calendars is a worthy thing, but probably best 
left for a third-party library.

> 2. Enable it in other fields except year.

That part is easy: replace `[0-9]` in regexes with `\d`.

> 3. Add tests for it. 

Aye, that would need to be done. Adding the tests would be the hard 
part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Fri Jan 10 03:12:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 08:12:49 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>
Message-ID: <1578643969.18.0.023011099167.issue39280@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Fri Jan 10 03:13:21 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jan 2020 08:13:21 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
In-Reply-To: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>
Message-ID: <1578644001.45.0.0682960577538.issue39235@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 850a8856e120f8cba15e557a0e791f93b43d6989 by Serhiy Storchaka in branch 'master':
bpo-39235: Check end_lineno and end_col_offset of AST nodes. (GH-17926)
https://github.com/python/cpython/commit/850a8856e120f8cba15e557a0e791f93b43d6989


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39235>
_______________________________________

From report at bugs.python.org  Fri Jan 10 03:15:16 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 10 Jan 2020 08:15:16 +0000
Subject: [issue39235] Generator expression has wrong line/col info when inside
 a Call object
In-Reply-To: <1578338847.26.0.00979384316229.issue39235@roundup.psfhosted.org>
Message-ID: <1578644116.79.0.848575148004.issue39235@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If somebody want to backport tests to 3.8, he must check manually all end positions.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39235>
_______________________________________

From report at bugs.python.org  Fri Jan 10 03:23:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 08:23:22 +0000
Subject: [issue39277] _PyTime_FromDouble() fails to detect an integer overflow
 when converting a C double to a C int64_t
In-Reply-To: <1578581025.66.0.18478821427.issue39277@roundup.psfhosted.org>
Message-ID: <1578644602.6.0.199118556483.issue39277@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

_PyTime_FromDouble() checks if!(_Py_DoubleInIntegralTypeRange(_PyTime_t, d)) with the macro:

#define _Py_InIntegralTypeRange(type, v) (_Py_IntegralTypeMin(type) <= v && v <= _Py_IntegralTypeMax(type))

and _Py_IntegralTypeMax(type)=2**63-1.

"v <= _Py_IntegralTypeMax(type)" compares a C double to a C int64_t: the compiler casts the C int64_t to a C double.

The problem is that 2**63-1 casted to a C double rounds using ROUND_HALF_EVEN rounding mode which gives a number *greater* than 2**63-1: we get 2**63.

To implement "v <= max", we have to round max towards zero (ROUND_DOWN), not round it using ROUND_HALF_EVEN.

I didn't find a way to control the rounding mode of casting C int64_t to C double, but we can round it *afterwards* using nextafter(max, 0.0) (ROUND_DOWN).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39277>
_______________________________________

From report at bugs.python.org  Fri Jan 10 03:26:58 2020
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Fri, 10 Jan 2020 08:26:58 +0000
Subject: [issue34311] locale.format() and locale.format_string() cast Decimals
 to float
In-Reply-To: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za>
Message-ID: <1578644818.61.0.442862411591.issue34311@roundup.psfhosted.org>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

For me, the name was natural as it is the reverse operation of the existing delocalize method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34311>
_______________________________________

From report at bugs.python.org  Fri Jan 10 03:55:34 2020
From: report at bugs.python.org (aggu)
Date: Fri, 10 Jan 2020 08:55:34 +0000
Subject: [issue39284] Flexible indentation
Message-ID: <1578646534.54.0.883213343126.issue39284@roundup.psfhosted.org>


New submission from aggu <agguser at gmail.com>:

Indentation should not be "too strict", any number of leading whitespaces greater that its "parent" or "peer" should be allowed. For example, the following code should be allow:

a = 1
# step 1
	# step 1.1
		a = a + 1
	# step 1.2
		a = a * 2
# step 2
	# ?

, which is more readable, I think, than:

a = 1
# step 1
# step 1.1
a = a + 1
# step 1.2
a = a * 2
# step 2
# ?

.

----------
messages: 359712
nosy: aggu
priority: normal
severity: normal
status: open
title: Flexible indentation
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39284>
_______________________________________

From report at bugs.python.org  Fri Jan 10 04:24:29 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 10 Jan 2020 09:24:29 +0000
Subject: [issue39166] Python 3.9.0a2 changed how "async for" traces its final
 iteration
In-Reply-To: <1577712159.27.0.774322517863.issue39166@roundup.psfhosted.org>
Message-ID: <1578648269.82.0.48028453298.issue39166@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 4c53e63cc966f98e141a09bc435b9f9c713b152d by Mark Shannon (Pablo Galindo) in branch 'master':
bpo-39166: Fix trace of last iteration of async for loops (#17800)
https://github.com/python/cpython/commit/4c53e63cc966f98e141a09bc435b9f9c713b152d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39166>
_______________________________________

From report at bugs.python.org  Fri Jan 10 04:30:55 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 10 Jan 2020 09:30:55 +0000
Subject: [issue39166] Python 3.9.0a2 changed how "async for" traces its final
 iteration
In-Reply-To: <1577712159.27.0.774322517863.issue39166@roundup.psfhosted.org>
Message-ID: <1578648655.23.0.787339248665.issue39166@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

I think this is now fixed.

Ned, feel free to reopen if it still isn't fixed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39166>
_______________________________________

From report at bugs.python.org  Fri Jan 10 04:38:43 2020
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 10 Jan 2020 09:38:43 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>
Message-ID: <1578649123.12.0.225141405533.issue39280@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

Okay, since it seems like I'm the only one who wants this change, I'll let it go. Thanks for your input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Fri Jan 10 04:47:19 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 10 Jan 2020 09:47:19 +0000
Subject: [issue39283] Add ability to inherit unittest arguement parser
In-Reply-To: <1578630738.78.0.369523186494.issue39283@roundup.psfhosted.org>
Message-ID: <1578649639.91.0.456189276647.issue39283@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please post the unittest script and the desired behavior? Are you testing your own argument parser created using argparse or want to write something replacing the argument parser of the unittest module like creating a custom unittest runner?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39283>
_______________________________________

From report at bugs.python.org  Fri Jan 10 04:51:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 09:51:13 +0000
Subject: [issue39277] _PyTime_FromDouble() fails to detect an integer overflow
 when converting a C double to a C int64_t
In-Reply-To: <1578581025.66.0.18478821427.issue39277@roundup.psfhosted.org>
Message-ID: <1578649873.3.0.886707012794.issue39277@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17338
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17933

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39277>
_______________________________________

From report at bugs.python.org  Fri Jan 10 05:06:56 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 10 Jan 2020 10:06:56 +0000
Subject: [issue39285] PurePath.match indicates case-sensitive nature and
 presents a case-insensitive example
Message-ID: <1578650816.04.0.399157633818.issue39285@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

https://docs.python.org/3/library/pathlib.html#pathlib.PurePath.match

Under PurePath.match there is a statement that case-sensitivity is followed but presents an example in Windows where case insensitive match returns True. This is confusing since match internally uses fnmatch.fnmatchcase that doesn't normalize case but in Windows files are case insensitive. Either the doc could be clarified that it's platform dependent or present a PosixPath example or present two examples with one for Linux and one for Windows that it's platform dependent.

As with other methods, case-sensitivity is observed:

>>> PureWindowsPath('b.py').match('*.PY')
True

----------
assignee: docs at python
components: Documentation
messages: 359717
nosy: docs at python, pitrou, serhiy.storchaka, xtreak
priority: normal
severity: normal
status: open
title: PurePath.match indicates case-sensitive nature and presents a case-insensitive example
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39285>
_______________________________________

From report at bugs.python.org  Fri Jan 10 06:28:23 2020
From: report at bugs.python.org (George Hickman)
Date: Fri, 10 Jan 2020 11:28:23 +0000
Subject: [issue35164] socket.getfqdn and socket.gethostbyname fail on MacOS
In-Reply-To: <1541350241.71.0.788709270274.issue35164@psf.upfronthosting.co.za>
Message-ID: <1578655703.26.0.666990411598.issue35164@roundup.psfhosted.org>


George Hickman <george+bugs-python-org at ghickman.co.uk> added the comment:

I came across this today with the same timeout behaviour on macOS 10.14.6.

After some digging I tracked it down to the Search Domains setting of my local network, this was set to "local", removing that immediately fixed the issue.

----------
nosy: +ghickman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35164>
_______________________________________

From report at bugs.python.org  Fri Jan 10 06:30:41 2020
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 10 Jan 2020 11:30:41 +0000
Subject: [issue39279] Don't allow non-Ascii digits in platform.py
In-Reply-To: <1578603731.26.0.701759063569.issue39279@roundup.psfhosted.org>
Message-ID: <1578655841.52.0.242278411469.issue39279@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Can you elaborate on the rational for this proposed change?  I'm not sure if there cases where the digits are non-ASCII, but if there are, is rejecting them the right thing to do?
In the code there's a comment that mentions that the Windows version can be localized, so if the version number uses non-ASCII digits and we change the regex to only accept [0-9], those version strings won't be accepted/recognized anymore.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39279>
_______________________________________

From report at bugs.python.org  Fri Jan 10 06:37:43 2020
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 10 Jan 2020 11:37:43 +0000
Subject: [issue39279] Don't allow non-Ascii digits in platform.py
In-Reply-To: <1578603731.26.0.701759063569.issue39279@roundup.psfhosted.org>
Message-ID: <1578656263.13.0.219772977572.issue39279@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

My approach is that any input that's unexpected by the developer but accepted by the program could cause either a bug or a security problem, and should be rejected by the program. I don't have a specific example for this case.

If you think I need to come up with a specific example where this can be misused, or show that there are no computers in the world that willingly use the version number with non-Ascii digits, I'll let this issue go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39279>
_______________________________________

From report at bugs.python.org  Fri Jan 10 06:54:59 2020
From: report at bugs.python.org (Alex Grund)
Date: Fri, 10 Jan 2020 11:54:59 +0000
Subject: [issue39286] Configure includes LIBS but does not pass it to distutils
Message-ID: <1578657299.08.0.201349832459.issue39286@roundup.psfhosted.org>


New submission from Alex Grund <flamefire89 at gmail.com>:

When configuring with `LIBS=-lpthread` env var set, the pthread detection assumes that no flag is necessary and distutils will build all extensions without any flag for pthreads. This will make them fail, when they use certain pthread symbols on certain platforms

Example: On Power9 libpthread is a linker script which does not only link in the dynamic library but also a static part which contains e.g. pthread_atfork. As the extension is linked against libpython and that is linked against libpthread the extension has access to all symbols from the dynamic library, but not to any from the static library (if one exists). This makes extensions fail to build on Power9.

Related issue as an example: https://github.com/scipy/scipy/issues/11323

EasyBuild is one example that builds Python with that env var set: https://github.com/easybuilders/easybuild-framework/issues/3154

Very related to https://bugs.python.org/issue31769 as the issue is similar: Flag passed during configure not used by distutils.

----------
components: Build, Distutils
messages: 359721
nosy: Alex Grund, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Configure includes LIBS but does not pass it to distutils
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39286>
_______________________________________

From report at bugs.python.org  Fri Jan 10 07:09:06 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 10 Jan 2020 12:09:06 +0000
Subject: [issue28143] ASDL compatibility with Python 3 system interpreter
In-Reply-To: <1473843180.28.0.653391200015.issue28143@psf.upfronthosting.co.za>
Message-ID: <1578658146.53.0.835132089779.issue28143@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28143>
_______________________________________

From report at bugs.python.org  Fri Jan 10 07:11:17 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 10 Jan 2020 12:11:17 +0000
Subject: [issue31829] Portability issues with pickle
In-Reply-To: <1508521289.37.0.213398074469.issue31829@psf.upfronthosting.co.za>
Message-ID: <1578658277.63.0.78104860749.issue31829@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31829>
_______________________________________

From report at bugs.python.org  Fri Jan 10 07:11:39 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 10 Jan 2020 12:11:39 +0000
Subject: [issue39287] Document UTF-8 mode in the using/windows.
Message-ID: <1578658299.42.0.446573986531.issue39287@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

I think the UTF-8 mode is very useful for Windows users.
Let's add section for the UTF-8 mode in the using/windows.

----------
assignee: docs at python
components: Documentation
messages: 359722
nosy: docs at python, inada.naoki
priority: normal
severity: normal
status: open
title: Document UTF-8 mode in the using/windows.
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39287>
_______________________________________

From report at bugs.python.org  Fri Jan 10 07:13:54 2020
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Fri, 10 Jan 2020 12:13:54 +0000
Subject: [issue12159] Integer Overflow in __len__
In-Reply-To: <1306160642.73.0.477719318482.issue12159@psf.upfronthosting.co.za>
Message-ID: <1578658434.95.0.718308617034.issue12159@roundup.psfhosted.org>


Change by Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:


----------
pull_requests: +17339
pull_request: https://github.com/python/cpython/pull/17934

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12159>
_______________________________________

From report at bugs.python.org  Fri Jan 10 07:13:55 2020
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Fri, 10 Jan 2020 12:13:55 +0000
Subject: [issue15718] Possible OverflowError in __len__ method undocumented
 (when called via len() function)
In-Reply-To: <1345202279.02.0.767068523185.issue15718@psf.upfronthosting.co.za>
Message-ID: <1578658435.07.0.248889220501.issue15718@roundup.psfhosted.org>


Change by Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:


----------
pull_requests: +17340
pull_request: https://github.com/python/cpython/pull/17934

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15718>
_______________________________________

From report at bugs.python.org  Fri Jan 10 07:13:55 2020
From: report at bugs.python.org (Zac Hatfield-Dodds)
Date: Fri, 10 Jan 2020 12:13:55 +0000
Subject: [issue21444] __len__ can't return big numbers
In-Reply-To: <1399331471.11.0.0301606352774.issue21444@psf.upfronthosting.co.za>
Message-ID: <1578658435.21.0.608709307446.issue21444@roundup.psfhosted.org>


Change by Zac Hatfield-Dodds <zac.hatfield.dodds at gmail.com>:


----------
pull_requests: +17341
pull_request: https://github.com/python/cpython/pull/17934

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21444>
_______________________________________

From report at bugs.python.org  Fri Jan 10 07:18:27 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 10 Jan 2020 12:18:27 +0000
Subject: [issue39287] Document UTF-8 mode in the using/windows.
In-Reply-To: <1578658299.42.0.446573986531.issue39287@roundup.psfhosted.org>
Message-ID: <1578658707.15.0.904869696234.issue39287@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +17342
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17935

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39287>
_______________________________________

From report at bugs.python.org  Fri Jan 10 07:29:05 2020
From: report at bugs.python.org (pingchao chen)
Date: Fri, 10 Jan 2020 12:29:05 +0000
Subject: [issue37527] Timestamp conversion on windows fails with timestamps
 close to EPOCH
In-Reply-To: <1562668345.09.0.775729583969.issue37527@roundup.psfhosted.org>
Message-ID: <1578659345.25.0.884901450412.issue37527@roundup.psfhosted.org>


Change by pingchao chen <pingchaoc at yeah.net>:


----------
keywords: +patch
pull_requests: +17343
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/15498

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37527>
_______________________________________

From report at bugs.python.org  Fri Jan 10 07:37:17 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 10 Jan 2020 12:37:17 +0000
Subject: [issue34110] cPickle may raise AttributeError when loading
 concurrently in threads
In-Reply-To: <1531507208.03.0.56676864532.issue34110@psf.upfronthosting.co.za>
Message-ID: <1578659837.43.0.731349356428.issue34110@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Fixed in Python 3 with #34572.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34110>
_______________________________________

From report at bugs.python.org  Fri Jan 10 07:45:19 2020
From: report at bugs.python.org (Yair Bonastre)
Date: Fri, 10 Jan 2020 12:45:19 +0000
Subject: [issue38259] having a PriorityQueue in multiprocessing.queue module
 like in queue module would be a plus
In-Reply-To: <1569249780.79.0.316857326171.issue38259@roundup.psfhosted.org>
Message-ID: <1578660319.65.0.0577459635392.issue38259@roundup.psfhosted.org>


Change by Yair Bonastre <bonastreyair at gmail.com>:


----------
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38259>
_______________________________________

From report at bugs.python.org  Fri Jan 10 08:43:58 2020
From: report at bugs.python.org (Mario Corchero)
Date: Fri, 10 Jan 2020 13:43:58 +0000
Subject: [issue39222] unittest.mock.Mock.parent is broken or undocumented
In-Reply-To: <1578236312.03.0.58171840403.issue39222@roundup.psfhosted.org>
Message-ID: <1578663838.37.0.00399598134046.issue39222@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

@cjw296 or @michael.foord might know why the attribute was exposed as plain "parent". It was added more than 8 years ago and I am unnable to follow the git commit history.

They should then decide whether this is intenteded to be used by the users (which I never have used on the init TBH) and therefore document it or whether it is a private name on the init and if in that case it would be worth trying to mangle it.

In the meantime, xtreak suggested workflow is probably the best to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39222>
_______________________________________

From report at bugs.python.org  Fri Jan 10 08:46:18 2020
From: report at bugs.python.org (Chris Withers)
Date: Fri, 10 Jan 2020 13:46:18 +0000
Subject: [issue39222] unittest.mock.Mock.parent is broken or undocumented
In-Reply-To: <1578236312.03.0.58171840403.issue39222@roundup.psfhosted.org>
Message-ID: <1578663978.01.0.482204633312.issue39222@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

I thought we'd already changed this to _mock_parent in the last year or so?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39222>
_______________________________________

From report at bugs.python.org  Fri Jan 10 09:11:17 2020
From: report at bugs.python.org (Mario Corchero)
Date: Fri, 10 Jan 2020 14:11:17 +0000
Subject: [issue39222] unittest.mock.Mock.parent is broken or undocumented
In-Reply-To: <1578236312.03.0.58171840403.issue39222@roundup.psfhosted.org>
Message-ID: <1578665477.47.0.533955468821.issue39222@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

If you refer to https://bugs.python.org/issue35357, this issue refers to `parent` at the time of creation of the mock. In the init it is still referenced as "parent".

The question is whether we want to also mangle "parent" in the __init__, as it seems it is not expected to be part of the API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39222>
_______________________________________

From report at bugs.python.org  Fri Jan 10 09:28:44 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 10 Jan 2020 14:28:44 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578666524.15.0.626331489036.issue39259@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17344
pull_request: https://github.com/python/cpython/pull/17936

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Fri Jan 10 09:34:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 14:34:12 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578666852.31.0.246516784809.issue39259@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset c39b52f1527868c7ada9385669c38edf98858921 by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-39259: poplib now rejects timeout = 0 (GH-17912)
https://github.com/python/cpython/commit/c39b52f1527868c7ada9385669c38edf98858921


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Fri Jan 10 10:03:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 15:03:44 +0000
Subject: [issue39277] _PyTime_FromDouble() fails to detect an integer overflow
 when converting a C double to a C int64_t
In-Reply-To: <1578581025.66.0.18478821427.issue39277@roundup.psfhosted.org>
Message-ID: <1578668624.58.0.462761329222.issue39277@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Similar issue in HHVM:

* https://github.com/facebook/hhvm/issues/5932
* https://github.com/PPC64/hhvm/commit/7cdb76b4f495aa7aa40a696379862916c27f5828

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39277>
_______________________________________

From report at bugs.python.org  Fri Jan 10 10:15:51 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Fri, 10 Jan 2020 15:15:51 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>
Message-ID: <1578669351.32.0.699821128583.issue39280@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> Yes, but not within the same format. If someone were to choose the format '2014-04-10T24:00:00', they would have a reasonable expectation that there is only one unique string that corresponds with that datetime

That's a particularly bad example, because it's exactly the same as another string with the exact same format:

  2014-04-11T00:00:00

Since ISO 8601 allows you to specify midnight (and only midnight) using previous day + 24:00. Admittedly, that is the only ambiguity I know of offhand (though it's a huge spec) *for a given format*, but also ISO 8601 does not really have a concept of format specifiers, so it's not like there's a way to unambiguously specify the format you are intending to use.

Either way, I think we can explicitly dispense with "there will be an exact mapping between a given (format_str, datetime_str) pair and the datetime it produces" as a goal here. I can't think of any good reason you'd want that property, nor have we made any indication that I can see that we provide it (probably the opposite, since there are some formats that explicitly ignore whitespace).

> Okay, since it seems like I'm the only one who wants this change, I'll let it go. Thanks for your input.

I wouldn't go that far. I think I am +0 or +1 on this change, I just wanted to be absolutely clear *why* we're doing this. I don't want someone pointing at this thread in the future and saying, "Core dev says that it's a bug in their code if they don't follow X standard / if more than one string produces the same datetime / etc".

I think the strongest argument for making this or a similar change is that I'm fairly certain that we don't have the bandwidth to handle internationalized dates and I don't think we have much to gain by doing a sort of half-assed version of that by accepting unicode transliterations of numerals and calling it a day. I think there are tons of edge cases here that could bite people, and if we don't support this *now* I'd rather give people an error message early in the process and try to point people at a library that is designed to handle datetime localization issues. If all we're going to do is switch [0-9] to \d (which won't work for the places where it's actually [1-9], mind you), I think people will get a better version of that with something like:

  def normalize_dt_str(dt_str):
      return "".join(str(int(x)) if x.isdigit() else x
                     for x in dt_str)

There are probably more robust and/or faster versions of this, but it's probably roughly equivalent to what we'd be doing here *anyway*, and at least people would have to opt-in to this.

I am definitely open to us supporting non-ASCII digits in strptime if it would be useful at the level of support we could provide, but given that it's currently broken for any reasonable use case and as far as I know no one has complained, we're better off resolving the inconsistency by requiring ASCII digits and considering non-ASCII support to be a separate feature request.

CC-ing Inada on this as unicode guru and because he might have some intuition about how useful non-ASCII support might be. The only place I've seen non-ASCII dates is in Japanese graveyards, and those tend to use Chinese numerals (which don't match \d anyway), though Japanese and Korean also tends to make heavier use of "full-width numerals" block, so maybe parsing something like "??????????" is an actual pain point that would be improved by this change (though, again, I suspect that this is just the beginning of the required changes and we may never get a decent implementation that supports unicode numerals).

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Fri Jan 10 10:40:49 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 10 Jan 2020 15:40:49 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578669351.32.0.699821128583.issue39280@roundup.psfhosted.org>
Message-ID: <20200110154027.GH839@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> If all we're going to do is 
> switch [0-9] to \d (which won't work for the places where it's 
> actually [1-9], mind you)

Ah, that's a good point.

[...]
> we're better off resolving the 
> inconsistency by requiring ASCII digits and considering non-ASCII 
> support to be a separate feature request.

This seems reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Fri Jan 10 10:51:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 15:51:22 +0000
Subject: [issue39288] Add math.nextafter(a, b)
Message-ID: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Linux manual page of nextafter():
"""
The nextafter() function return the next representable floating-point  value following x in the direction of y.  If y is less than x, these functions will return the largest representable number less than x.

If x equals y, the functions return y.
"""

I used this function to round an integer towards zero when casting a float to an integer in bpo-39277. Example in C:

#include <math.h>
#include <stdio.h>
#include <stdint.h>
int main()
{
    int64_t int64_max = 9223372036854775807LL;
    double d = (double)int64_max;  /* ROUND_HALF_EVEN */
    double d2 = nextafter(d, 0.0);
    printf("i = %ld\n", int64_max);
    printf("d = %.0f\n", d);
    printf("d2 = %.0f\n", d2);
    printf("d - d2 = %.0f\n", d - d2);
    return 0;
}

Output:

i = 9223372036854775807
d = 9223372036854775808
d2 = 9223372036854774784
d - d2 = 1024

The function exists in numpy:

numpy.nextafter(x1, x2, /, out=None, *, where=True, casting='same_kind', order='K', dtype=None, subok=True[, signature, extobj]) = <ufunc 'nextafter'>

    Return the next floating-point value after x1 towards x2, element-wise.

https://docs.scipy.org/doc/numpy/reference/generated/numpy.nextafter.html


Attached PR adds math.nextafter().

----------
components: Library (Lib)
messages: 359731
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add math.nextafter(a, b)
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Fri Jan 10 10:53:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 15:53:46 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578671626.11.0.600440994546.issue39288@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +3.3regression
nosy: +lemburg, mark.dickinson, rhettinger, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Fri Jan 10 10:53:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 15:53:57 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578671637.77.0.649227639277.issue39288@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17345
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17937

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Fri Jan 10 10:56:01 2020
From: report at bugs.python.org (Chris Burr)
Date: Fri, 10 Jan 2020 15:56:01 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1578671761.29.0.796209349098.issue18233@roundup.psfhosted.org>


Change by Chris Burr <christopher.burr at cern.ch>:


----------
pull_requests: +17346
pull_request: https://github.com/python/cpython/pull/17938

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:21:48 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jan 2020 16:21:48 +0000
Subject: [issue39289] crypt.crypt crashes on 3.9 where it didn't on 3.8
Message-ID: <1578673308.87.0.447911789122.issue39289@roundup.psfhosted.org>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

The following script (cryptest.py):

import crypt

for salt in ('foo', '$2a$04$5BJqKfqMQvV7nS.yUguNcueVirQqDBGaLXSqj.rs.pZPlNR0UX/HK'):
    t = 'test'
    h = crypt.crypt(t, salt)
    print("'%s' with '%s' -> %s" % (t, salt, h))

crashes in 3.9, whereas it doesn't in earlier versions:

$ python2.7 cryptest.py 
'test' with 'foo' -> foy6TgL.HboTE
'test' with '$2a$04$5BJqKfqMQvV7nS.yUguNcueVirQqDBGaLXSqj.rs.pZPlNR0UX/HK' -> None
$ python3.7 cryptest.py 
'test' with 'foo' -> foy6TgL.HboTE
'test' with '$2a$04$5BJqKfqMQvV7nS.yUguNcueVirQqDBGaLXSqj.rs.pZPlNR0UX/HK' -> None
$ python3.8 cryptest.py 
'test' with 'foo' -> foy6TgL.HboTE
'test' with '$2a$04$5BJqKfqMQvV7nS.yUguNcueVirQqDBGaLXSqj.rs.pZPlNR0UX/HK' -> None
$ python3.9 cryptest.py 
'test' with 'foo' -> foy6TgL.HboTE
Traceback (most recent call last):
  File "/home/vinay/projects/scratch/cpython/cryptest.py", line 5, in <module>
    h = crypt.crypt(t, salt)
  File "/home/vinay/.local/lib/python3.9/crypt.py", line 82, in crypt
    return _crypt.crypt(word, salt)
OSError: [Errno 22] Invalid argument

This is on Ubuntu 18.04, 64-bit.

----------
components: Library (Lib)
keywords: 3.9regression
messages: 359732
nosy: vinay.sajip
priority: normal
severity: normal
status: open
title: crypt.crypt crashes on 3.9 where it didn't on 3.8
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39289>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:26:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 16:26:39 +0000
Subject: [issue39289] crypt.crypt crashes on 3.9 where it didn't on 3.8
In-Reply-To: <1578673308.87.0.447911789122.issue39289@roundup.psfhosted.org>
Message-ID: <1578673599.72.0.279985395678.issue39289@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I fail to reproduce the issue on the master branch of Python on Fedora 31.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39289>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:27:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 16:27:03 +0000
Subject: [issue39289] crypt.crypt fail with OSError "[Errno 22] Invalid
 argument" on 3.9 where it didn't on 3.8
In-Reply-To: <1578673308.87.0.447911789122.issue39289@roundup.psfhosted.org>
Message-ID: <1578673623.91.0.241858373154.issue39289@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: crypt.crypt crashes on 3.9 where it didn't on 3.8 -> crypt.crypt fail with OSError "[Errno 22] Invalid argument" on 3.9 where it didn't on 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39289>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:29:08 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 10 Jan 2020 16:29:08 +0000
Subject: [issue39289] crypt.crypt fail with OSError "[Errno 22] Invalid
 argument" on 3.9 where it didn't on 3.8
In-Reply-To: <1578673308.87.0.447911789122.issue39289@roundup.psfhosted.org>
Message-ID: <1578673748.42.0.817808865267.issue39289@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I also fail to reproduce the issue on the master branch of Python on macOS.

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39289>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:31:06 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 10 Jan 2020 16:31:06 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1578673866.58.0.669261857647.issue13305@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In issue39103, I filed a bug relating to this issue.

I'd like for Python to provide a portable implementation of strftime instead of just documenting that the version isn't portable.

Given that this ticket assigned to 'docs' suggests that a portable version is out of the question. Can we expand the scope of this issue to actually providing a portable version?

----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13305>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:31:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 16:31:51 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578673911.7.0.755615637659.issue39200@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset abdc634f337ce4943cd7d13587936837aac2ecc9 by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-39200: Correct the error message for min/max builtin function (GH-17814)
https://github.com/python/cpython/commit/abdc634f337ce4943cd7d13587936837aac2ecc9


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39200>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:32:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 16:32:41 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578673961.29.0.623419631433.issue39200@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Dong-hee, Pablo: Should we backport the two fixes to 3.7 and 3.8 branches? IMHO yes, we should backport.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39200>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:40:51 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 10 Jan 2020 16:40:51 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578674451.55.0.960603238271.issue39200@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Victor: Changes are only correcting the message.
I am +1 on backporting :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39200>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:45:09 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Jan 2020 16:45:09 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578674709.67.0.286077308778.issue39200@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17347
pull_request: https://github.com/python/cpython/pull/17940

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39200>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:45:17 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Jan 2020 16:45:17 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578674717.54.0.835101301761.issue39200@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17348
pull_request: https://github.com/python/cpython/pull/17941

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39200>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:45:39 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Jan 2020 16:45:39 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578674739.16.0.680685755234.issue39200@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17349
pull_request: https://github.com/python/cpython/pull/17942

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39200>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:45:46 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 10 Jan 2020 16:45:46 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578674746.12.0.723764631947.issue39200@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17350
pull_request: https://github.com/python/cpython/pull/17943

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39200>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:47:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 16:47:16 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578674836.53.0.873090417939.issue39200@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Backport PRs are ready for 3.7 and 3.8. Question: is there a risk of breaking the backward compatibility if a project unit test rely on the exact error message? If yes, maybe it's better to reject the backports and close this issue (only change the error message in 3.9).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39200>
_______________________________________

From report at bugs.python.org  Fri Jan 10 11:47:43 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 10 Jan 2020 16:47:43 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578674863.67.0.88381483909.issue39259@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17351
pull_request: https://github.com/python/cpython/pull/17939

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Fri Jan 10 12:07:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 17:07:46 +0000
Subject: [issue13305] datetime.strftime("%Y") not consistent for years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1578676066.23.0.511574527409.issue13305@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I'd like for Python to provide a portable implementation of strftime instead of just documenting that the version isn't portable.

If someone wants to do that, I suggest to first start with a project on PyPI. It sounds like a tricky project. Date, time, locales and localization are hard problems!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13305>
_______________________________________

From report at bugs.python.org  Fri Jan 10 12:13:12 2020
From: report at bugs.python.org (Xu)
Date: Fri, 10 Jan 2020 17:13:12 +0000
Subject: [issue39241] Popen of python3.6 hangs on os.read(errpipe_read, 50000)
In-Reply-To: <1578360908.03.0.624419556785.issue39241@roundup.psfhosted.org>
Message-ID: <1578676392.27.0.275206701932.issue39241@roundup.psfhosted.org>


Xu <liuxu1005 at gmail.com> added the comment:

Thanks Stinner.

Do you have some clues about this issue ?
In my case, our test system use Popen to start a few infrastructure processes for tests going. After tests done we will kill all processes and start again for new round.

Most of time it works fine.  However we have some chances where one Popen hangs on "os.read(errpipe_read, 50000) forever.

The close_fd is always true.

I guess there is some subtle issue here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39241>
_______________________________________

From report at bugs.python.org  Fri Jan 10 12:16:47 2020
From: report at bugs.python.org (Batuhan)
Date: Fri, 10 Jan 2020 17:16:47 +0000
Subject: [issue39290] lib2to3.fixes.fix_import: support imports_as_name in
 traverse_imports
Message-ID: <1578676607.69.0.963910000582.issue39290@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

I've been working on custom lib2to3 fixers and I use some of the already definied utilites inside the fixers. But traverse_imports can't traverse from import names, which is pretty simple and straight forward to implement.

----------
messages: 359742
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: lib2to3.fixes.fix_import: support imports_as_name in traverse_imports

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39290>
_______________________________________

From report at bugs.python.org  Fri Jan 10 12:21:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 10 Jan 2020 17:21:08 +0000
Subject: [issue39241] Popen of python3.6 hangs on os.read(errpipe_read, 50000)
In-Reply-To: <1578360908.03.0.624419556785.issue39241@roundup.psfhosted.org>
Message-ID: <1578676868.22.0.91546127834.issue39241@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I have no clue. Try to attach a debugger and try to inspect the Python frames. You can use gdb with python-gdb.py for that, for example. Or play with faulthandler, especially faulthandler.dump_traceback_later().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39241>
_______________________________________

From report at bugs.python.org  Fri Jan 10 12:24:28 2020
From: report at bugs.python.org (Batuhan)
Date: Fri, 10 Jan 2020 17:24:28 +0000
Subject: [issue39290] lib2to3.fixes.fix_import: support imports_as_name in
 traverse_imports
In-Reply-To: <1578676607.69.0.963910000582.issue39290@roundup.psfhosted.org>
Message-ID: <1578677068.87.0.853205214108.issue39290@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +17352
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17944

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39290>
_______________________________________

From report at bugs.python.org  Fri Jan 10 12:45:10 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 10 Jan 2020 17:45:10 +0000
Subject: [issue39284] Flexible indentation
In-Reply-To: <1578646534.54.0.883213343126.issue39284@roundup.psfhosted.org>
Message-ID: <1578678310.01.0.335697038538.issue39284@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Please discuss this idea on the python-ideas mailing list first. It would also certainly require a PEP.

But I don't want to get your hopes up: there's almost no chance that this would be accepted.

I'm going to close this issue. If the idea gains any traction, we can re-open it.

----------
nosy: +eric.smith
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39284>
_______________________________________

From report at bugs.python.org  Fri Jan 10 12:50:14 2020
From: report at bugs.python.org (Rockmizu)
Date: Fri, 10 Jan 2020 17:50:14 +0000
Subject: [issue39291] "pathlib.Path.link_to()" and "pathlib.Path.symlink_to()"
 have reversed usage
Message-ID: <1578678614.26.0.0980677925629.issue39291@roundup.psfhosted.org>


New submission from Rockmizu <Rockmizu at gmail.com>:

Python version: Python 3.8.1 (tags/v3.8.1:1b293b6, Dec 18 2019, 23:11:46) [MSC v.1916 64 bit (AMD64)] on win32

The usage of symlink_to() is link.symlink_to(target)
while the usage of link_to() is target.link_to(link).
This could be confusing.

Here is an example:

>>> import pathlib
>>> target = pathlib.Path('target.txt')
>>> p1 = pathlib.Path('symlink.txt')
>>> p2 = pathlib.Path('hardlink.txt')
>>> p1.symlink_to(target)
>>> p2.link_to(target)  # expected usage
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "D:\Program Files\Python38\lib\pathlib.py", line 1346, in link_to
    self._accessor.link_to(self, target)
FileNotFoundError: [WinError 2] The system cannot find the file specified: 'hardlink.txt' -> 'target.txt'
>>> target.link_to(p2)  # current usage
>>>

Since os.symlink() and os.link() have the same argument order,

>>> import os
>>> os.symlink('target.txt', 'symlink.txt')
>>> os.link('target.txt', 'hardlink.txt')
>>>

it would be nicer if the pathlib has the same argument order too.

----------
components: Library (Lib)
messages: 359745
nosy: Rockmizu
priority: normal
severity: normal
status: open
title: "pathlib.Path.link_to()" and "pathlib.Path.symlink_to()" have reversed usage
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39291>
_______________________________________

From report at bugs.python.org  Fri Jan 10 12:54:35 2020
From: report at bugs.python.org (Ryan)
Date: Fri, 10 Jan 2020 17:54:35 +0000
Subject: [issue39292] syslog constants behind rfc
Message-ID: <1578678875.77.0.925015529037.issue39292@roundup.psfhosted.org>


New submission from Ryan <tryanunderwood at gmail.com>:

When using the SysLogHandler (https://docs.python.org/3/library/logging.handlers.html#logging.handlers.SysLogHandler) the supported facilities appear to be lagging the RFC (5454 ?), or at least what is being supported in other mainstream languages. I Specifically need LOG_AUDIT and LOG_NTP but there are a couple others. The syslog "openlog" function takes an INT but not sure how to get an INT through the python SysLogHandler because it's based on a static list of names and symbolic values.
Wikipedia (https://en.wikipedia.org/wiki/Syslog#Facility) suggests LOG_AUTH and LOG_NTP are in the RFC. 
This is my first ticket here so hopefully this is the right place for it. Maybe there is a workaround or some re-education needed on my part...

----------
components: Library (Lib)
messages: 359746
nosy: tryanunderwood at gmail.com
priority: normal
severity: normal
status: open
title: syslog constants behind rfc
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39292>
_______________________________________

From report at bugs.python.org  Fri Jan 10 13:11:41 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 10 Jan 2020 18:11:41 +0000
Subject: [issue39291] "pathlib.Path.link_to()" and "pathlib.Path.symlink_to()"
 have reversed usage
In-Reply-To: <1578678614.26.0.0980677925629.issue39291@roundup.psfhosted.org>
Message-ID: <1578679901.54.0.59026507628.issue39291@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39291>
_______________________________________

From report at bugs.python.org  Fri Jan 10 13:12:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 10 Jan 2020 18:12:24 +0000
Subject: [issue39292] syslog constants behind rfc
In-Reply-To: <1578678875.77.0.925015529037.issue39292@roundup.psfhosted.org>
Message-ID: <1578679944.32.0.657987677828.issue39292@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39292>
_______________________________________

From report at bugs.python.org  Fri Jan 10 13:14:20 2020
From: report at bugs.python.org (SilentGhost)
Date: Fri, 10 Jan 2020 18:14:20 +0000
Subject: [issue39292] syslog constants behind rfc
In-Reply-To: <1578678875.77.0.925015529037.issue39292@roundup.psfhosted.org>
Message-ID: <1578680060.17.0.0960409915283.issue39292@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
type:  -> behavior
versions:  -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39292>
_______________________________________

From report at bugs.python.org  Fri Jan 10 13:35:20 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jan 2020 18:35:20 +0000
Subject: [issue39291] "pathlib.Path.link_to()" and "pathlib.Path.symlink_to()"
 have reversed usage
In-Reply-To: <1578678614.26.0.0980677925629.issue39291@roundup.psfhosted.org>
Message-ID: <1578681320.56.0.37520147847.issue39291@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ahah. Nice catch!

Well, it's a pity this got overlooked when we added Path.link_to().  But I'm afraid it's late to change it now, since this has been released, and changing the argument order would break existing code in potentially dangerous ways.

Note the original issue where this was added was issue26978.

----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39291>
_______________________________________

From report at bugs.python.org  Fri Jan 10 13:37:28 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 10 Jan 2020 18:37:28 +0000
Subject: [issue39291] "pathlib.Path.link_to()" and "pathlib.Path.symlink_to()"
 have reversed usage
In-Reply-To: <1578678614.26.0.0980677925629.issue39291@roundup.psfhosted.org>
Message-ID: <1578681448.01.0.86830172506.issue39291@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Closing as won't fix.  If you feel strongly about this, I would suggest to bring the discussion on python-dev: https://mail.python.org/mailman3/lists/python-dev.python.org/

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39291>
_______________________________________

From report at bugs.python.org  Fri Jan 10 13:56:07 2020
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 10 Jan 2020 18:56:07 +0000
Subject: [issue39204] Automate adding Type Annotations to Documentation
In-Reply-To: <1578078745.51.0.848404810387.issue39204@roundup.psfhosted.org>
Message-ID: <1578682567.18.0.308496690822.issue39204@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39204>
_______________________________________

From report at bugs.python.org  Fri Jan 10 14:16:05 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jan 2020 19:16:05 +0000
Subject: [issue39292] syslog constants behind rfc
In-Reply-To: <1578678875.77.0.925015529037.issue39292@roundup.psfhosted.org>
Message-ID: <1578683765.2.0.298835131229.issue39292@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
keywords: +patch
pull_requests: +17353
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17945

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39292>
_______________________________________

From report at bugs.python.org  Fri Jan 10 14:17:18 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 10 Jan 2020 19:17:18 +0000
Subject: [issue39257] contextvars.Context.run hangs forever in
 ProccessPoolExecutor
In-Reply-To: <1578479674.06.0.280894954081.issue39257@roundup.psfhosted.org>
Message-ID: <1578683838.04.0.319434205343.issue39257@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
Removed message: https://bugs.python.org/msg359576

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39257>
_______________________________________

From report at bugs.python.org  Fri Jan 10 14:23:50 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 10 Jan 2020 19:23:50 +0000
Subject: [issue39257] contextvars.Context.run hangs forever in
 ProccessPoolExecutor
In-Reply-To: <1578479674.06.0.280894954081.issue39257@roundup.psfhosted.org>
Message-ID: <1578684230.07.0.721575911393.issue39257@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> This throws 'cannot pickle Context' 

Yes, this is expected. contextvars are not compatible with multiprocessing.

> **** This hangs forever *****

This hanging part is weird, and most likely hints at a bug in multiprocessing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39257>
_______________________________________

From report at bugs.python.org  Fri Jan 10 14:37:54 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jan 2020 19:37:54 +0000
Subject: [issue39292] syslog constants behind rfc
In-Reply-To: <1578678875.77.0.925015529037.issue39292@roundup.psfhosted.org>
Message-ID: <1578685074.88.0.34086329733.issue39292@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset ce54519aa09772f4173b8c17410ed77e403f3ebf by Vinay Sajip in branch 'master':
bpo-39292: Add missing syslog facility codes. (GH-17945)
https://github.com/python/cpython/commit/ce54519aa09772f4173b8c17410ed77e403f3ebf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39292>
_______________________________________

From report at bugs.python.org  Fri Jan 10 14:45:05 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jan 2020 19:45:05 +0000
Subject: [issue39289] crypt.crypt fail with OSError "[Errno 22] Invalid
 argument" on 3.9 where it didn't on 3.8
In-Reply-To: <1578673308.87.0.447911789122.issue39289@roundup.psfhosted.org>
Message-ID: <1578685505.0.0.144441008753.issue39289@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I can also reproduce it on Ubuntu 16.04.6 LTS (the first Ubuntu was the Linux Mint version based on Ubuntu 18.04).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39289>
_______________________________________

From report at bugs.python.org  Fri Jan 10 14:58:19 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jan 2020 19:58:19 +0000
Subject: [issue39289] crypt.crypt fail with OSError "[Errno 22] Invalid
 argument" on 3.9 where it didn't on 3.8
In-Reply-To: <1578673308.87.0.447911789122.issue39289@roundup.psfhosted.org>
Message-ID: <1578686299.24.0.27297634603.issue39289@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Another data point: both failing machines were VMware virtual machines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39289>
_______________________________________

From report at bugs.python.org  Fri Jan 10 15:03:38 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 10 Jan 2020 20:03:38 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578686618.71.0.752599930292.issue39288@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm not opposed to some form of this by any means, but I fear there's some bikeshedding to go through, both on the name and the functionality (one function with two arguments, or two functions each taking a single argument?).

C 99 prescribes "nextafter" and "nexttoward" (which is pretty much the same as "nextafter" if you don't care about the distinction between float, double and long double).

IEEE 754, on the other hand, requires instead nextUp and nextDown, which take a single argument and move towards +inf or -inf (respectively).

Python's Decimal type has a two-argument next_toward method.

NumPy has nextafter.

Java provides all three of nextUp, nextDown and nextAfter.

For sure implementing nextafter is easiest, since we can just wrap the C version. That doesn't *necessarily* make it the right variant to go for.

(Annoyingly enough, none of these is actually what I tend to want in practice, which is "next larger" and "next smaller" functions, or more precisely, nextAwayFromZero and nextTowardsZero functions. nextTowardsZero is of course a special case of nextafter, but nextAwayFromZero doesn't match any of these.)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Fri Jan 10 15:38:01 2020
From: report at bugs.python.org (Maxime Belanger)
Date: Fri, 10 Jan 2020 20:38:01 +0000
Subject: [issue34297] Windows py.exe launcher fail to handle quote correctly
In-Reply-To: <1533058834.14.0.56676864532.issue34297@psf.upfronthosting.co.za>
Message-ID: <1578688681.23.0.591929505393.issue34297@roundup.psfhosted.org>


Change by Maxime Belanger <max at dropbox.com>:


----------
nosy: +Maxime Belanger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34297>
_______________________________________

From report at bugs.python.org  Fri Jan 10 15:51:10 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Jan 2020 20:51:10 +0000
Subject: [issue1531415] parsetok.c emits warnings by writing to stderr
Message-ID: <1578689470.43.0.587245225592.issue1531415@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Pablo, is this still a thing to care about?

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1531415>
_______________________________________

From report at bugs.python.org  Fri Jan 10 15:51:41 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Jan 2020 20:51:41 +0000
Subject: [issue1596321] KeyError at exit after 'import threading' in other
 thread
Message-ID: <1578689501.32.0.483075150647.issue1596321@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1596321>
_______________________________________

From report at bugs.python.org  Fri Jan 10 15:53:49 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Jan 2020 20:53:49 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1578689629.14.0.388479156983.issue1674555@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1674555>
_______________________________________

From report at bugs.python.org  Fri Jan 10 15:55:22 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Jan 2020 20:55:22 +0000
Subject: [issue2636] Adding a new regex module (compatible with re)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1578689722.49.0.724929036712.issue2636@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Jan 10 15:55:50 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Jan 2020 20:55:50 +0000
Subject: [issue4347] Circular dependency causes SystemError when adding new
 syntax
In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za>
Message-ID: <1578689750.24.0.57754252564.issue4347@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
resolution: wont fix -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4347>
_______________________________________

From report at bugs.python.org  Fri Jan 10 15:56:19 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 10 Jan 2020 20:56:19 +0000
Subject: [issue4347] Circular dependency causes SystemError when adding new
 syntax
In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za>
Message-ID: <1578689779.65.0.0542582836549.issue4347@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Pablo, is this still an issue?

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4347>
_______________________________________

From report at bugs.python.org  Fri Jan 10 16:11:34 2020
From: report at bugs.python.org (Tony)
Date: Fri, 10 Jan 2020 21:11:34 +0000
Subject: [issue39293] Windows 10 64-bit needs reboot
Message-ID: <1578690694.46.0.197073018811.issue39293@roundup.psfhosted.org>


New submission from Tony <factoryx.code at gmail.com>:

After installing python 3.8.1 64-bit, on Windows 10 64-bit version 1909, the system needs to be rebooted to validate all settings in the registry. Otherwise will cause a lot of exceptions, like Path not found etc.

----------
components: Installation
messages: 359756
nosy: ToKa
priority: normal
severity: normal
status: open
title: Windows 10 64-bit needs reboot
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39293>
_______________________________________

From report at bugs.python.org  Fri Jan 10 16:12:14 2020
From: report at bugs.python.org (Juan Arrivillaga)
Date: Fri, 10 Jan 2020 21:12:14 +0000
Subject: [issue39247] dataclass defaults and property don't work together
In-Reply-To: <1578418537.56.0.0565923550129.issue39247@roundup.psfhosted.org>
Message-ID: <1578690734.78.0.342485873106.issue39247@roundup.psfhosted.org>


Juan Arrivillaga <juanpa.arrivillaga at gmail.com> added the comment:

So, after glancing at the source code:
https://github.com/python/cpython/blob/ce54519aa09772f4173b8c17410ed77e403f3ebf/Lib/dataclasses.py#L869

During this processing of fields, couldn't you just special case property/descriptor objects?

----------
nosy: +juanpa.arrivillaga

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39247>
_______________________________________

From report at bugs.python.org  Fri Jan 10 16:20:48 2020
From: report at bugs.python.org (Batuhan)
Date: Fri, 10 Jan 2020 21:20:48 +0000
Subject: [issue39292] syslog constants behind rfc
In-Reply-To: <1578678875.77.0.925015529037.issue39292@roundup.psfhosted.org>
Message-ID: <1578691248.29.0.829039558064.issue39292@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@vinay.sajip PR 17945 looks resolved this, can this issue be closed?

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39292>
_______________________________________

From report at bugs.python.org  Fri Jan 10 16:27:12 2020
From: report at bugs.python.org (Batuhan)
Date: Fri, 10 Jan 2020 21:27:12 +0000
Subject: [issue19557] ast - docs for every node type are missing
In-Reply-To: <1384239144.67.0.857427270426.issue19557@psf.upfronthosting.co.za>
Message-ID: <1578691632.97.0.403933301188.issue19557@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

@pablogsal is working on documenting nodes (not every node type that exists, the ones that aren't deprecated) in PR 17812

----------
nosy: +BTaskaya, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19557>
_______________________________________

From report at bugs.python.org  Fri Jan 10 16:40:19 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jan 2020 21:40:19 +0000
Subject: [issue39292] syslog constants behind rfc
In-Reply-To: <1578678875.77.0.925015529037.issue39292@roundup.psfhosted.org>
Message-ID: <1578692419.24.0.503209454262.issue39292@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> can this issue be closed?

Not quite yet. Waiting for feedback from the original reporter as to whether this change meets the requirements. I've also treated this as an enhancement rather than a bug, and so I am not currently planning to back-port these changes. I will close this issue once I get feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39292>
_______________________________________

From report at bugs.python.org  Fri Jan 10 16:48:58 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jan 2020 21:48:58 +0000
Subject: [issue39289] crypt.crypt fail with OSError "[Errno 22] Invalid
 argument" on 3.9 where it didn't on 3.8
In-Reply-To: <1578673308.87.0.447911789122.issue39289@roundup.psfhosted.org>
Message-ID: <1578692938.96.0.49872081836.issue39289@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It appears that a check for the return value from the crypt/crypt_r primitives was added to fix bpo-38402. So, this is expected behaviour in Python 3.9. Change was in

https://github.com/python/cpython/commit/0d3fe8ae4961bf551e7d5e42559e2ede1a08fd7c

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39289>
_______________________________________

From report at bugs.python.org  Fri Jan 10 16:57:59 2020
From: report at bugs.python.org (Bram Stolk)
Date: Fri, 10 Jan 2020 21:57:59 +0000
Subject: [issue39294] zipfile.ZipInfo objects contain invalid 'extra' fields.
Message-ID: <1578693479.87.0.550823648689.issue39294@roundup.psfhosted.org>


New submission from Bram Stolk <b.stolk at gmail.com>:

This has been tested with Windows Python 2.7 and Python 3.8

If you get the ZipInfo objects of a ZIP file that is larger than 2GiB, then all the ZipInfo entries with a header offset > 2G will report phantom 'extra' data.

import zipfile
zipname = "reallybig.zip"
z = zipfile.ZipFile( zipname )
zi = z.infolist()
for inf in zi:
      print( inf.filename, inf.header_offset, inf.extra )  

And observe that:
* All entries with offset < 2G will report no extra field.
* All entries with offset > 2G will report extra field.

It's hard to package this up as a self-contained test, because it requires a very large zip to test.

----------
components: IO
messages: 359762
nosy: Bram Stolk
priority: normal
severity: normal
status: open
title: zipfile.ZipInfo objects contain invalid 'extra' fields.
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39294>
_______________________________________

From report at bugs.python.org  Fri Jan 10 17:16:07 2020
From: report at bugs.python.org (Matthew Newville)
Date: Fri, 10 Jan 2020 22:16:07 +0000
Subject: [issue39295] usage of bitfields in ctypes structures changed between
 3.7.5 and 3.7.6
Message-ID: <1578694567.2.0.498689301236.issue39295@roundup.psfhosted.org>


New submission from Matthew Newville <matt.newville at gmail.com>:

We have a library (https://github.com/pyepics/pyepics) that wraps several C structures for a communication protocol library that involves many C->Python callbacks.  One of the simpler structures we wrap with ctypes is defined with

typedef struct ca_access_rights {
    unsigned    read_access:1;
    unsigned    write_access:1; } caar;

struct  access_rights_handler_args {
    long  chanId; /* channel id */
    caar  access; /* access rights state */
};

which we had wrapped (perhaps naively) as 

class access_rights_handler_args(ctypes.Structure):
    "access rights arguments"
    _fields_ = [('chid', ctypes.c_long),
                ('read_access', ctypes.c_uint, 1),
                ('write_access', ctypes.c_uint, 1)]

which we would then this structure as the function argument of a callback function that the underlying library would call, using

    _Callback = ctypes.CFUNCTYPE(None, ctypes.POINTER(access_rights_handler_args))(access_rights_handler)

and the python function `access_righte_handler` would be able to unpack and use this structure.  This worked for Python 2.7, 3.3 - 3.7.5 on 64-bit Linux, Windows, and MacOS.  This code was well-tested and was used in production code on very many systems. It did not cause segfaults.

With Python 3.7.6 this raises an exception at the ctypes.CFUNCTYPE() call with


...../lib/python3.7/ctypes/__init__.py", line 99, in CFUNCTYPE
    class CFunctionType(_CFuncPtr):
TypeError: item 1 in _argtypes_ passes a struct/union with a bitfield by value, which is unsupported.


We were able to find a quick work-around this by changing the structure definition to be

class access_rights_handler_args(ctypes.Structure):
    "access rights arguments"
    _fields_ = [('chid', ctypes.c_long),
                ('access', ctypes.c_ubyte)]

and then explicitly extract the 2 desired bits from the byte. Of course, that byte is more data than is being sent in the structure, so there is trailing garbage.

This change seems to have been related to https://bugs.python.org/issue16576.

Is there any way to restore the no-really-I'm-not-making-it-up-it-was-most-definitely-working-for-us behavior of Python 3.7.5 and earlier?  

If this is not possible, what would be the right way to wrap this sort of structure? Thanks

----------
components: ctypes
messages: 359763
nosy: Matthew Newville
priority: normal
severity: normal
status: open
title: usage of bitfields in ctypes structures changed between 3.7.5 and 3.7.6
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39295>
_______________________________________

From report at bugs.python.org  Fri Jan 10 17:24:53 2020
From: report at bugs.python.org (Juan Arrivillaga)
Date: Fri, 10 Jan 2020 22:24:53 +0000
Subject: [issue39247] dataclass defaults and property don't work together
In-Reply-To: <1578418537.56.0.0565923550129.issue39247@roundup.psfhosted.org>
Message-ID: <1578695093.82.0.228581040402.issue39247@roundup.psfhosted.org>


Juan Arrivillaga <juanpa.arrivillaga at gmail.com> added the comment:

Actually, couldn't the following be a workaround, just set the property on the class after the class definition:


import dataclasses
import typing
@dataclasses.dataclass
class FileObject:
    uploaded_by:typing.Optional[None]=None

    def _uploaded_by_getter(self):
        return self._uploaded_by

    def _uploaded_by_setter(self, uploaded_by):
        print('Setter Called with Value ', uploaded_by)
        self._uploaded_by = uploaded_by

FileObject.uploaded_by = property(
    FileObject._uploaded_by_getter,
    FileObject._uploaded_by_setter
)
p = FileObject()
print(p)
print(p.uploaded_by)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39247>
_______________________________________

From report at bugs.python.org  Fri Jan 10 17:24:56 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 10 Jan 2020 22:24:56 +0000
Subject: [issue17013] Allow waiting on a mock
In-Reply-To: <1358856947.82.0.71016271567.issue17013@psf.upfronthosting.co.za>
Message-ID: <1578695096.71.0.737067331962.issue17013@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17013>
_______________________________________

From report at bugs.python.org  Fri Jan 10 17:26:27 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 10 Jan 2020 22:26:27 +0000
Subject: [issue38567] urllib.parse.unquote_plus raises incorrect error message
 when string parameter is bytes
In-Reply-To: <1571852750.66.0.0310766347617.issue38567@roundup.psfhosted.org>
Message-ID: <1578695187.75.0.739553841898.issue38567@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38567>
_______________________________________

From report at bugs.python.org  Fri Jan 10 17:28:07 2020
From: report at bugs.python.org (Tony)
Date: Fri, 10 Jan 2020 22:28:07 +0000
Subject: [issue39296] Windows register keys
Message-ID: <1578695287.77.0.549625073253.issue39296@roundup.psfhosted.org>


New submission from Tony <factoryx.code at gmail.com>:

It would be more practical to name the Windows main registry keys 'python', with for example 'python32' or 'python64'. This would make searching the registry for registered python versions (single and/or multi users) a lot easier.

----------
components: Windows
messages: 359765
nosy: ToKa, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows register keys
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39296>
_______________________________________

From report at bugs.python.org  Fri Jan 10 17:34:59 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 10 Jan 2020 22:34:59 +0000
Subject: [issue38901] [venv] Add a CLI flag to venv to use the pwd basename as
 the prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1578695699.06.0.600103964712.issue38901@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
keywords: +patch
pull_requests: +17354
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17946

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Fri Jan 10 17:35:03 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 10 Jan 2020 22:35:03 +0000
Subject: [issue32021] Brotli encoding is not recognized by mimetypes
In-Reply-To: <1510645430.68.0.213398074469.issue32021@psf.upfronthosting.co.za>
Message-ID: <1578695703.42.0.966516382412.issue32021@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Now that two years have passed, is there any additional info as to whether this should be added or not?  It does seem that the format is active (https://github.com/google/brotli).

----------
nosy: +cheryl.sabella
versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32021>
_______________________________________

From report at bugs.python.org  Fri Jan 10 17:36:17 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 10 Jan 2020 22:36:17 +0000
Subject: [issue36556] Trashcan causing duplicated __del__ calls
In-Reply-To: <1554721069.78.0.635003677155.issue36556@roundup.psfhosted.org>
Message-ID: <1578695777.26.0.810211694554.issue36556@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36556>
_______________________________________

From report at bugs.python.org  Fri Jan 10 17:37:20 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 10 Jan 2020 22:37:20 +0000
Subject: [issue36516] Python Launcher can not recognize pyw file as Python GUI
 Script file type correctly.
In-Reply-To: <1554272827.64.0.548414335806.issue36516@roundup.psfhosted.org>
Message-ID: <1578695840.7.0.683578114422.issue36516@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36516>
_______________________________________

From report at bugs.python.org  Fri Jan 10 17:47:21 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 10 Jan 2020 22:47:21 +0000
Subject: [issue17254] add thai encoding aliases to encodings.aliases
In-Reply-To: <1361360924.27.0.663240022367.issue17254@psf.upfronthosting.co.za>
Message-ID: <1578696441.04.0.84116484358.issue17254@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions: +Python 3.9 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17254>
_______________________________________

From report at bugs.python.org  Fri Jan 10 17:56:41 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Jan 2020 22:56:41 +0000
Subject: [issue39207] concurrent.futures.ProcessPoolExecutor does not properly
 reap jobs and spawns too many workers
In-Reply-To: <1578087844.56.0.81762061225.issue39207@roundup.psfhosted.org>
Message-ID: <1578697001.71.0.30753705195.issue39207@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +bquinlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39207>
_______________________________________

From report at bugs.python.org  Fri Jan 10 18:01:43 2020
From: report at bugs.python.org (apmatthews)
Date: Fri, 10 Jan 2020 23:01:43 +0000
Subject: [issue38330] httplib specifies content-length when transfer-encoding
 present
In-Reply-To: <1569875041.02.0.374553203578.issue38330@roundup.psfhosted.org>
Message-ID: <1578697303.05.0.921635692099.issue38330@roundup.psfhosted.org>


apmatthews <apmatthews at gmail.com> added the comment:

ping :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38330>
_______________________________________

From report at bugs.python.org  Fri Jan 10 18:10:47 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Jan 2020 23:10:47 +0000
Subject: [issue39217] GC of a ctypes object causes application crash
In-Reply-To: <1578189599.82.0.182987253345.issue39217@roundup.psfhosted.org>
Message-ID: <1578697847.51.0.186245301148.issue39217@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

"Is this a bug" questions are often better asked on python-list.  (I don't know.)  If so, the bug needed to be tested on the current development version (3.9 now).  Likely, someone on python-list will try given reproducible code.


2.7 has reach EOL.

----------
nosy: +terry.reedy
versions: +Python 3.9 -Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39217>
_______________________________________

From report at bugs.python.org  Fri Jan 10 18:29:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Jan 2020 23:29:00 +0000
Subject: [issue39219] Fix attributes of syntax errors raized in the tokenizer
In-Reply-To: <1578224025.61.0.7633610275.issue39219@roundup.psfhosted.org>
Message-ID: <1578698940.91.0.693169735179.issue39219@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On entry of '0xz', IDLE from 3.6 to date highlights the '0x' part of the original entry.  I presume it can do this because it ignores the text attribute, and because bytes == chars for at least  '0x'.

The 'proposed PR' is not listed here.  Is it not yet submitted, or is the issue number wrong?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39219>
_______________________________________

From report at bugs.python.org  Fri Jan 10 19:32:09 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jan 2020 00:32:09 +0000
Subject: [issue39228] traceback.FrameSummary does not handle exceptions from
 `repr()`
In-Reply-To: <1578284065.37.0.657086816746.issue39228@roundup.psfhosted.org>
Message-ID: <1578702729.62.0.00781039887943.issue39228@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As is true for most special methods, it is a bug for __repr__ methods to raise.  They should return a string, as documented.

Special method wrappers generally assume that the wrapped methods work.  In particular, repr assumes this, and so do the __repr__ methods of all collections classes.  They do not try to hide bugs.  Example:

>>> class BadRep:
	def __repr__(self): 1/0

	
>>> br = BadRep()
>>> [br]
Traceback (most recent call last):
  File "<pyshell#8>", line 1, in <module>
    [br]
  File "C:\Programs\Python39\lib\idlelib\rpc.py", line 620, in displayhook
    text = repr(value)
  File "<pyshell#6>", line 2, in __repr__
    def __repr__(self): 1/0
ZeroDivisionError: division by zero

Bugs should be reported, not masked.  I don't think that FrameSummary should be an exception to this.  Therefore I think that this issue should be closed (along with the PR) as 'not a bug'.

----------
nosy: +terry.reedy
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39228>
_______________________________________

From report at bugs.python.org  Fri Jan 10 19:43:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Jan 2020 00:43:44 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578703424.86.0.0443123657711.issue39288@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> NumPy has nextafter.

That's why I proposed math.nextafter() name.

Moreover, in the math module, most functions reuse the same names than C function names: expm1(), atan2(), erf(), etc.


> IEEE 754, on the other hand, requires instead nextUp and nextDown, which take a single argument and move towards +inf or -inf (respectively).

When I played with bpo-39277, I used nextafter() to try to implement manually a conversion from an integer to a float using rounding towards zero. So I prefer nextafter() than nextUp()/nextDown(): it gives more features.


> but nextAwayFromZero doesn't match any of these

It seems easy to reimplement it using nextafter(), no?

def nextAwayFromZero(x):
    if x < 0:
        return math.nextafter(x, -float("inf"))
    else:
        return math.nextafter(x, +float("inf"))


> Python's Decimal type has a two-argument next_toward method.

It also has next_minus() and next_plus() which don't match "nextUp and nextDown" names requires by IEEE 754.

I'm not comfortable with math.next_after() or math.next_toward() name: use a different than the libc function name (add an underscore). For me, the math module is a thin wrapper to libm function, as the os module is a thin wrapper to libc functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Fri Jan 10 19:52:47 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jan 2020 00:52:47 +0000
Subject: [issue39231] Mistaken notion in tutorial
In-Reply-To: <1578334311.83.0.989380005846.issue39231@roundup.psfhosted.org>
Message-ID: <1578703967.52.0.483982111405.issue39231@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

https://docs.python.org/3/tutorial/controlflow.html#function-annotations
is the direct link.

As Mark said, 'ham' is a required positional-or-keyword argument.
'eggs' is an optional 'positional-or-keyword.  The sentence as is is wrong, even if Robert garbled the reason.  With the signature as it, the sentence should be "The following example has a required argument, an optional argument, and the return value annotated."

To make the existing sentence true, the signature could be changed to
  def f(ham: str, /, *, eggs: str) -> str:
But I think this would be wrong.  Annotation does not depend on how an argument is passed, but whether it has a default (making it optional).  In particular, it shows that when optional, the annotation goes *before* '= default', not after.  (It could have gone after: eggs = 'eggs': str.)

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39231>
_______________________________________

From report at bugs.python.org  Fri Jan 10 20:04:50 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jan 2020 01:04:50 +0000
Subject: [issue39249] difflib SequenceMatcher 200 char length limitation for
 ratio calculation
In-Reply-To: <1578426179.61.0.269122492915.issue39249@roundup.psfhosted.org>
Message-ID: <1578704690.92.0.502451665095.issue39249@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> difflib SequenceMatcher ratio() still have unpredictable behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39249>
_______________________________________

From report at bugs.python.org  Fri Jan 10 20:09:02 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 11 Jan 2020 01:09:02 +0000
Subject: [issue39297] Synchronize importlib.metadata with importlib_metadata
 1.4
Message-ID: <1578704942.47.0.915059602595.issue39297@roundup.psfhosted.org>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

Importlib_metadata 1.4 adds performance improvements to the distribution discovery mechanism. Let's incorporate those upstream.

----------
components: Library (Lib)
messages: 359773
nosy: jaraco
priority: normal
severity: normal
status: open
title: Synchronize importlib.metadata with importlib_metadata 1.4
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39297>
_______________________________________

From report at bugs.python.org  Fri Jan 10 20:11:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jan 2020 01:11:53 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1578705113.25.0.135830618745.issue39274@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: https://bugs.python.org/msg359674

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39274>
_______________________________________

From report at bugs.python.org  Fri Jan 10 20:14:43 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 11 Jan 2020 01:14:43 +0000
Subject: [issue39297] Synchronize importlib.metadata with importlib_metadata
 1.4
In-Reply-To: <1578704942.47.0.915059602595.issue39297@roundup.psfhosted.org>
Message-ID: <1578705283.95.0.660429823966.issue39297@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +17355
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17947

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39297>
_______________________________________

From report at bugs.python.org  Fri Jan 10 20:14:50 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 11 Jan 2020 01:14:50 +0000
Subject: [issue39275] Traceback off by one line when
In-Reply-To: <1578576348.64.0.412986299263.issue39275@roundup.psfhosted.org>
Message-ID: <1578705290.76.0.0254693089854.issue39275@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39275>
_______________________________________

From report at bugs.python.org  Fri Jan 10 21:23:39 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 11 Jan 2020 02:23:39 +0000
Subject: [issue39247] dataclass defaults and property don't work together
In-Reply-To: <1578418537.56.0.0565923550129.issue39247@roundup.psfhosted.org>
Message-ID: <1578709419.65.0.983168117706.issue39247@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

> During this processing of fields, couldn't you just special case property/descriptor objects?

What if you want the field to be a descriptor?

I think the best way of handling this would be to use some sentinel value for the default, and if found look up the value on the instance, not the class.

But I'm a little worried this might break something else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39247>
_______________________________________

From report at bugs.python.org  Fri Jan 10 21:42:59 2020
From: report at bugs.python.org (Tim Peters)
Date: Sat, 11 Jan 2020 02:42:59 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578710579.92.0.0323900426704.issue39288@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

No doubt that something along these lines would be useful.

`nextafter()` is too widely implemented to fight against, despite the sucky name ;-)

I believe the rest should be straightforward (for those who want them) to do with one-liners, so there's not much of a case for building them in.  Or is that wrong?  My guesses for correct implementations:

def nextUp(x):
    return math.nextafter(x, math.inf)

def nextDown(x):
    return math.nextafter(x, -math.inf)

def nextAwayFromZero(x):
    return math.nextafter(x, math.copysign(math.inf, x))
    
That last assumes you want -0 and +0 to act differently; i.e., want

    nextAwayFromZero(0.0) == 5e-324
and
    nextAwayFromZero(-0.0) == -5e-324

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Fri Jan 10 23:18:48 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 11 Jan 2020 04:18:48 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1578716328.46.0.965193375631.issue39200@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

CPython or stdlib: There is no code depends on the error message of range and min/max.
3rd party: IMHO, if somebody relies on the error message, not error type, I think that the code pattern is bad usage

And as I mentioned on msg359243, other python compatible compilers/interpreters already don't follow the same error message as CPython. 
If the issue had been caused by this issue, it would have already been reported. But it doesn't seem to be.

So my conclusion is that it will not be a problem. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39200>
_______________________________________

From report at bugs.python.org  Fri Jan 10 23:27:40 2020
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 11 Jan 2020 04:27:40 +0000
Subject: [issue39298] add BLAKE3 to hashlib
Message-ID: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>


New submission from Larry Hastings <larry at hastings.org>:

>From 3/4 of the team that brought you BLAKE2, now comes... BLAKE3!

https://github.com/BLAKE3-team/BLAKE3

BLAKE3 is a brand new hashing function.  It's fast, it's paralellizeable, and unlike BLAKE2 there's only one variant.

I've experimented with it a little.  On my laptop (2018 Intel i7 64-bit), the portable implementation is kind of middle-of-the-pack, but with AVX2 enabled it's second only to the "Haswell" build of KangarooTwelve.  On a 32-bit ARMv7 machine the results are more impressive--the portable implementation is neck-and-neck with MD4, and with NEON enabled it's definitely the fastest hash function I tested.  These tests are all single-threaded and eliminate I/O overhead.

The above Github repo has a reference implementation in C which includes Intel and ARM SIMD drivers.  Unsurprisingly, the interface looks roughly the same as the BLAKE2 interface(s), so if you took the existing BLAKE2 module and s/blake2b/blake3/ you'd be nearly done.  Not quite as close as blake2b and blake2s though ;-)

----------
components: Library (Lib)
keywords: patch
messages: 359777
nosy: Zooko.Wilcox-O'Hearn, christian.heimes, larry
priority: normal
severity: normal
stage: needs patch
status: open
title: add BLAKE3 to hashlib
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Fri Jan 10 23:30:24 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sat, 11 Jan 2020 04:30:24 +0000
Subject: [issue39207] concurrent.futures.ProcessPoolExecutor does not properly
 reap jobs and spawns too many workers
In-Reply-To: <1578087844.56.0.81762061225.issue39207@roundup.psfhosted.org>
Message-ID: <1578717024.9.0.621441956171.issue39207@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> What "ignores the max_workers argument" means?

>From my understanding, their argument was that the parameter name "max_workers" and documentation implies that it will spawn processes as needed up to *max_workers* based on the number of jobs scheduled. 

> And would you create a simple reproducible example?

I can't speak directly for the OP, but this simple example may demonstrate what they're talking about:

Linux 5.4.8
Python 3.8.1

```
import concurrent.futures as cf
import os
import random

def get_rand_nums(ls, n):
    return [random.randint(1, 100) for i in range(n)]
    
def show_processes():
    print("All python processes:")
    os.system("ps -C python")

def main():
    nums = []
    with cf.ProcessPoolExecutor(max_workers=6) as executor:
        futs = []
        show_processes()
        for _ in range(3):
            fut = executor.submit(get_rand_nums, nums, 10_000_000)
            futs.append(fut)
        show_processes()
        for fut in cf.as_completed(futs):
            nums.extend(fut.result())
        show_processes()

    assert len(nums) == 30_000_000

if __name__ == '__main__':
    main()
```

Output:

```
[aeros:~/programming/python]$ python ppe_max_workers.py
All python processes: # Main python process
    PID TTY          TIME CMD
  23683 pts/1    00:00:00 python
All python processes: # Main python process + 6 unused subprocesses
    PID TTY          TIME CMD
  23683 pts/1    00:00:00 python
  23685 pts/1    00:00:00 python
  23686 pts/1    00:00:00 python
  23687 pts/1    00:00:00 python
  23688 pts/1    00:00:00 python
  23689 pts/1    00:00:00 python
  23690 pts/1    00:00:00 python
All python processes: # Main python process + 3 used subprocesses + 3 unused subprocesses
    PID TTY          TIME CMD
  23683 pts/1    00:00:00 python
  23685 pts/1    00:00:07 python
  23686 pts/1    00:00:07 python
  23687 pts/1    00:00:07 python
  23688 pts/1    00:00:00 python
  23689 pts/1    00:00:00 python
  23690 pts/1    00:00:00 python
```

As seen above, all processes up to *max_workers* were spawned immediately after the jobs were submitted to ProcessPoolExecutor, regardless of the actual number of jobs (3). It is also apparent that only three of those spawned processes were utilized by the CPU, as indicated by the values in the TIME field. The other three processes were not used.

If it wasn't for this behavior, I think there would be a significant performance loss, as the executor would have to continuously calculate how many processes are needed and spawn them throughout it's lifespan. AFAIK, it _seems_ more efficient to spawn *max_workers* processes when the jobs are scheduled, and then use them as needed; rather than spawning the processes as needed.

As a result, I think the current behavior should remain the same; unless someone can come up with a backwards-compatible alternative version and demonstrate its advantages over the current one.

However, I do think the current documentation could do a better at explaining how max_workers actually behaves. See the current explanation: https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.ProcessPoolExecutor.

The current version does not address any of the above points. In fact, the first line seems like it might imply the opposite of what it's actually doing (at least based on my above example):

"An Executor subclass that executes calls asynchronously *using a pool of at most max_workers processes*." (asterisks added for emphasis)

"using a pool of at most max_workers processes" could imply to users that *max_workers* sets an upper bound limit on the number of processes in the pool, but that *max_workers* is only reached if all of those processes are _needed_. Unless I'm misunderstanding something, that's not the case.

I would suggest converting this into a documentation issue, assuming that the experts for the concurrent.futures confirm that the present behavior is intentional and that I'm correctly understanding the OP.

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39207>
_______________________________________

From report at bugs.python.org  Sat Jan 11 00:32:29 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 11 Jan 2020 05:32:29 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578720749.11.0.44223205269.issue39288@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I agree, "nextafter" is so widely used it's probably pointless to fight against the name :-)

Mark: "IEEE 754, on the other hand, requires instead nextUp and nextDown".

I know Wikipedia isn't a primary source, but it says IEEE 754 recommends nextafter(x, y).

My understanding of IEEE-754 is that the functionality is required, not the specific API. That is, it's not required to have literally two functions called "nextUp" and "nextDown", so long as you can get the next larger and next smaller float.

I think the second argument should also be optional, so that nextafter(x) returns the next representable float.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sat Jan 11 00:45:35 2020
From: report at bugs.python.org (Tim Peters)
Date: Sat, 11 Jan 2020 05:45:35 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578721535.96.0.0435671449775.issue39288@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

[Steven]
> I think the second argument should also be optional, so
> that nextafter(x) returns the next representable float.

That's why the name sucks - there are, in general, two adjacent floats, so "next" is ambiguous.  I expect you intend that y default to math.inf, which would make one-argument `nextafter(x)` a spelling of `nextUp(x)`.  Fine by me!  That's probably the one I want most often.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:06:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 11 Jan 2020 06:06:36 +0000
Subject: [issue39299] Improve test coverage for mimetypes module
Message-ID: <1578722796.76.0.475900715527.issue39299@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

Currently the test coverage for mimetypes module is at 57% https://codecov.io/gh/python/cpython/src/43682f1e39a3c61f0e8a638b887bcdcbfef766c5/Lib/mimetypes.py . I propose adding the following tests to increase the coverage.

* Add test for case insensitive check of types and extensions.
* Add test for data url with no comma.
* Add test for read_mime_types function.
* Add tests for the mimetypes cli.

----------
components: Tests
messages: 359781
nosy: xtreak
priority: normal
severity: normal
status: open
title: Improve test coverage for mimetypes module
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39299>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:07:16 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 11 Jan 2020 06:07:16 +0000
Subject: [issue39299] Improve test coverage for mimetypes module
In-Reply-To: <1578722796.76.0.475900715527.issue39299@roundup.psfhosted.org>
Message-ID: <1578722836.25.0.840134228143.issue39299@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch
pull_requests: +17356
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17949

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39299>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:17:15 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 11 Jan 2020 06:17:15 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1578723435.38.0.292335689149.issue39298@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:19:09 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 11 Jan 2020 06:19:09 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1578723549.35.0.500957028364.issue39298@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:21:26 2020
From: report at bugs.python.org (lijok)
Date: Sat, 11 Jan 2020 06:21:26 +0000
Subject: [issue39300] dataclasses non-default argument follows default argument
Message-ID: <1578723686.9.0.201746303828.issue39300@roundup.psfhosted.org>


New submission from lijok <egecas at live.co.uk>:

from dataclasses import dataclass


@dataclass
class A:
    PARAM: int


@dataclass
class B(A):
    ARG: int
    PARAM: int = 1

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "C:\Users\user\AppData\Local\Programs\Python\Python38\lib\dataclasses.py", line 1021, in dataclass
    return wrap(cls)
  File "C:\Users\user\AppData\Local\Programs\Python\Python38\lib\dataclasses.py", line 1013, in wrap
    return _process_class(cls, init, repr, eq, order, unsafe_hash, frozen)
  File "C:\Users\user\AppData\Local\Programs\Python\Python38\lib\dataclasses.py", line 927, in _process_class
    _init_fn(flds,
  File "C:\Users\user\AppData\Local\Programs\Python\Python38\lib\dataclasses.py", line 503, in _init_fn
    raise TypeError(f'non-default argument {f.name!r} '
TypeError: non-default argument 'ARG' follows default argument

----------
components: Library (Lib)
messages: 359782
nosy: eric.smith, lijok
priority: normal
severity: normal
status: open
title: dataclasses non-default argument follows default argument
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39300>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:35:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 11 Jan 2020 06:35:24 +0000
Subject: [issue39300] dataclasses non-default argument follows default argument
In-Reply-To: <1578723686.9.0.201746303828.issue39300@roundup.psfhosted.org>
Message-ID: <1578724524.28.0.432186160258.issue39300@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> TypeError will be raised if a field without a default value follows a field with a default value. This is true either when this occurs in a single class, or as a result of class inheritance.

I think this is a combination of the above statement at end of [0] and inheritance following the order of the fields at [1]

[0] https://docs.python.org/3/library/dataclasses.html#dataclasses.dataclass
[1] https://docs.python.org/3/library/dataclasses.html#inheritance

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39300>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:38:44 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 11 Jan 2020 06:38:44 +0000
Subject: [issue39300] dataclasses non-default argument follows default argument
In-Reply-To: <1578723686.9.0.201746303828.issue39300@roundup.psfhosted.org>
Message-ID: <1578724724.93.0.806199148104.issue39300@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also issue36077

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39300>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:39:02 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 11 Jan 2020 06:39:02 +0000
Subject: [issue38704] Prevent installation on unsupported Windows versions
In-Reply-To: <1572983678.12.0.905160936522.issue38704@roundup.psfhosted.org>
Message-ID: <1578724742.22.0.876142170066.issue38704@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +17357
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17950

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38704>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:44:34 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 11 Jan 2020 06:44:34 +0000
Subject: [issue38704] Prevent installation on unsupported Windows versions
In-Reply-To: <1572983678.12.0.905160936522.issue38704@roundup.psfhosted.org>
Message-ID: <1578725074.76.0.0468302275876.issue38704@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38704>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:47:52 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 11 Jan 2020 06:47:52 +0000
Subject: [issue17718] boolop constant checking for if/while
In-Reply-To: <1365873477.58.0.16753210186.issue17718@psf.upfronthosting.co.za>
Message-ID: <1578725272.4.0.8853187304.issue17718@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I think this issue should be closed.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17718>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:57:03 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 11 Jan 2020 06:57:03 +0000
Subject: [issue17718] boolop constant checking for if/while
In-Reply-To: <1365873477.58.0.16753210186.issue17718@psf.upfronthosting.co.za>
Message-ID: <1578725823.22.0.65460351367.issue17718@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17718>
_______________________________________

From report at bugs.python.org  Sat Jan 11 01:59:45 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Jan 2020 06:59:45 +0000
Subject: [issue39301] Specification of bitshift on integers should clearly
 state floor division used
Message-ID: <1578725984.98.0.631488660974.issue39301@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

While reviewing ISO-IECJTC1-SC22-WG23's latest draft of their Python security annex, I noticed that https://docs.python.org/3.7/library/stdtypes.html#bitwise-operations-on-integer-types doesn't explicitly state that *floor* division is used for right shift operations, so right-shifting a negative number by more bits than it contains gives -1 rather than 0.

This is consistent with the way the language spec defines both binary right-shifts (as division by "pow(2, n)" and floor division (as rounding towards negative infinity), so this is just a documentation issue to note that we should make it clearer that this behaviour is intentional.

----------
assignee: docs at python
components: Documentation
messages: 359786
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Specification of bitshift on integers should clearly state floor division used
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39301>
_______________________________________

From report at bugs.python.org  Sat Jan 11 02:13:46 2020
From: report at bugs.python.org (lijok)
Date: Sat, 11 Jan 2020 07:13:46 +0000
Subject: [issue39300] dataclasses non-default argument follows default argument
In-Reply-To: <1578723686.9.0.201746303828.issue39300@roundup.psfhosted.org>
Message-ID: <1578726826.67.0.433640400613.issue39300@roundup.psfhosted.org>


lijok <egecas at live.co.uk> added the comment:

> I think this is a combination of the above statement at end of [0] and inheritance following the order of the fields at [1]

Ah, I see, so if I understand correctly the init method for the example given would become __init__(self, PARAM: int = 1, ARG: int) since the fields are kept in an ordered mapping

Thank you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39300>
_______________________________________

From report at bugs.python.org  Sat Jan 11 03:41:52 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Jan 2020 08:41:52 +0000
Subject: [issue39302] Language reference does not clearly describe modern
 operand coercion
Message-ID: <1578732112.23.0.558996012972.issue39302@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

While reviewing ISO-IECJTC1-SC22-WG23's latest draft of their Python security annex, I found a description of operand coercion that was based on the legacy coercion model described at https://docs.python.org/2.5/ref/coercion-rules.html

That's still the second highest link if you search for "Python operand coercion", while the highest link is this old, very brief, summary from Python in a Nutshell: https://www.oreilly.com/library/view/python-in-a/0596001886/ch04s05.html (still based on the old semantics where the inputs were coerced to a common type before calling the slot method, rather than giving the method direct access to the original operands).

The third highest link at least goes to PEP 208 (https://www.python.org/dev/peps/pep-0208/), which correctly describes the modern semantics, but it describes them in terms of the CPython C slot API, not the Python level special method APIs.

https://docs.python.org/3.7/reference/datamodel.html#emulating-numeric-types does technically provide the required information, but it's implicit in the description of the numeric arithmetic methods, rather than being clearly spelled out as a clear description of "Python operand coercion". (There are also some oddities around operand coercion for three-argument pow() that I'm going to file as their own issue)

https://docs.python.org/3/library/constants.html#NotImplemented references https://docs.python.org/3/library/numbers.html#implementing-the-arithmetic-operations which describes defining new numeric ABCs in a coercion-friendly way, but still doesn't spell out the operand precedence and coercion dance.

We could likely improve this situation by adding a new "Special method invocation" subject at the end of https://docs.python.org/3.7/reference/datamodel.html, moving the existing "Special method lookup" subsection under it, and then adding a second subsection called "Operand precedence and coercion".

That new subsection would then cover the basic principles of:

* for unary operands, there is no ambiguity
* for binary operands of the same type, only the forward operation is tried (it is assumed that if the forward operation doesn't work, the reflected one won't either)
* for binary operands where the type of the RHS is a subclass of the type of the LHS, the reflected operation is tried first (if it exists), followed by the forward operation if the reflected call does not exist or returns the NotImplemented singleton
* for binary operands of unrelated types, the forward operation is tried first (if it exists), followed by the reflected operation if the forward call does not exist or returns the NotImplemented singleton
* for ternary operands (i.e. 3 argument pow()), the behaviour is currently implementation defined (as the test suite doesn't enforce any particular behaviour, and what CPython does isn't obviously useful)

Other specific points to be covered would be:

* any argument coercion that occurs is up to the individual method implementations
* logical short-circuiting expressions (and, or, if/else) only call the equivalent of bool(expr)

While the corresponding reflected operations for the binary operators are covered in the documentation of the forward operations, it would also likely be worthwhile including a summary table in this new subsection of exactly which special methods support reflection, and what the reflected method names are.

----------
messages: 359788
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Language reference does not clearly describe modern operand coercion
type: enhancement
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39302>
_______________________________________

From report at bugs.python.org  Sat Jan 11 04:52:17 2020
From: report at bugs.python.org (Dan Arad)
Date: Sat, 11 Jan 2020 09:52:17 +0000
Subject: [issue39303] Refactor cmd module
Message-ID: <1578736336.99.0.232991806531.issue39303@roundup.psfhosted.org>


New submission from Dan Arad <dan1994 at gmail.com>:

I've stumbled across the `cmd` module, had some difficulties in reading it, and wanted to help in making it more readable.

I'm new to contributing to open source, and thought this could be a good exercise for me, and that if I could contribute along the way, then that would be a nice extra.

I would be glad if my efforts could be accompanied by someone more experienced.

----------
components: Library (Lib)
messages: 359789
nosy: Dan Arad
priority: normal
severity: normal
status: open
title: Refactor cmd module
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39303>
_______________________________________

From report at bugs.python.org  Sat Jan 11 04:58:23 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Jan 2020 09:58:23 +0000
Subject: [issue39303] Refactor cmd module
In-Reply-To: <1578736336.99.0.232991806531.issue39303@roundup.psfhosted.org>
Message-ID: <1578736703.35.0.3578304206.issue39303@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17358
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17951

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39303>
_______________________________________

From report at bugs.python.org  Sat Jan 11 05:40:34 2020
From: report at bugs.python.org (Steve Holden)
Date: Sat, 11 Jan 2020 10:40:34 +0000
Subject: [issue34311] locale.format() and locale.format_string() cast Decimals
 to float
In-Reply-To: <1533154971.69.0.56676864532.issue34311@psf.upfronthosting.co.za>
Message-ID: <1578739234.85.0.762066475749.issue34311@roundup.psfhosted.org>


Steve Holden <steve at holdenweb.com> added the comment:

Verified. Methododology:

1. Copied test_localise.py from the PR into a master checkout.
2. Added a null locale.localize.
3. Verified that all new tests failed.

.. code-block::

  Ran 64 tests in 0.023s

  FAILED (errors=4, skipped=4)
  (base) blockhead:cpython sholden$ vi Lib/locale.py
  (base) blockhead:cpython sholden$ ./python.exe -m test.test_locale
  ...................ssss....F...................testing with ('tr_TR', 'ISO8859-9') .....testing with 'en_US.UTF-8'... .testing with 'en_US.UTF-8'... .testing with 'en_US.UTF-8'... .testing with 'en_US.UTF-8'... .testing with 'en_US.UTF-8'... .testing with 'en_US.UTF-8'... .testing with 'en_US.UTF-8'... .testing with 'en_US.UTF-8'... ....F
  ======================================================================
  FAIL: test_localize_invalid_format (__main__.TestEnUSLocalize)
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File "/Users/sholden/cpython/Lib/test/test_locale.py", line 613, in test_localize_invalid_format
      locale.localize('foo')
  AssertionError: ValueError not raised

  ======================================================================
  FAIL: test_localize (__main__.TestfrFRLocalize)
  ----------------------------------------------------------------------
  Traceback (most recent call last):
    File "/Users/sholden/cpython/Lib/test/test_locale.py", line 625, in test_localize
      self._test_localize('50000.00', '50000,00')
    File "/Users/sholden/cpython/Lib/test/test_locale.py", line 601, in _test_localize
      self.assertEqual(locale.localize(value, grouping=grouping), out)
  AssertionError: '50000.00' != '50000,00'
  - 50000.00
  ?      ^
  + 50000,00
  ?      ^


  ----------------------------------------------------------------------
  Ran 64 tests in 0.024s

  FAILED (failures=2, skipped=4)

4. Checked out cedk/locale_format branch.
5. Observed that all locale tests now pass.

Seems to me like this one should be good to go, so I've changed the stage to "commit review" and await the application of some core developer's commit bit.

----------
nosy: +holdenweb
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34311>
_______________________________________

From report at bugs.python.org  Sat Jan 11 05:51:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 11 Jan 2020 10:51:31 +0000
Subject: [issue39219] Fix attributes of syntax errors raized in the tokenizer
In-Reply-To: <1578224025.61.0.7633610275.issue39219@roundup.psfhosted.org>
Message-ID: <1578739891.28.0.627915720518.issue39219@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +17360
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17828

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39219>
_______________________________________

From report at bugs.python.org  Sat Jan 11 05:59:53 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 11 Jan 2020 10:59:53 +0000
Subject: [issue39219] Fix attributes of syntax errors raized in the tokenizer
In-Reply-To: <1578224025.61.0.7633610275.issue39219@roundup.psfhosted.org>
Message-ID: <1578740393.33.0.706953975188.issue39219@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Sorry, wrong issue number.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39219>
_______________________________________

From report at bugs.python.org  Sat Jan 11 07:45:38 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 11 Jan 2020 12:45:38 +0000
Subject: [issue26515] Update extending/embedding docs to new way to build
 modules in C
In-Reply-To: <1457491421.2.0.684118231911.issue26515@psf.upfronthosting.co.za>
Message-ID: <1578746738.63.0.570593124166.issue26515@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Changed target version as per Petr's comment (PEP 573 is close to being accepted for 3.9 - it just needs some editing to improve clarity in the PEP itself, rather than needing any changes to the technical proposal)

----------
versions: +Python 3.9 -Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26515>
_______________________________________

From report at bugs.python.org  Sat Jan 11 08:00:59 2020
From: report at bugs.python.org (Ryan)
Date: Sat, 11 Jan 2020 13:00:59 +0000
Subject: [issue39292] syslog constants behind rfc
In-Reply-To: <1578678875.77.0.925015529037.issue39292@roundup.psfhosted.org>
Message-ID: <1578747659.91.0.739750945521.issue39292@roundup.psfhosted.org>


Ryan <tryanunderwood at gmail.com> added the comment:

Thank you, this looks good. I'm pinned to 3.6 so while it won't work for me currently, maybe it will in a few years.
For clarity and because I can't edit my original message, the RFC is 5424 (I had mistakenly said 5454 but you got it right).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39292>
_______________________________________

From report at bugs.python.org  Sat Jan 11 08:37:00 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 11 Jan 2020 13:37:00 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1578749820.36.0.248897538894.issue39298@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I've been playing with the new algorithm, too. Pretty impressive!

Let's give the reference implementation a while to stabilize. The code has comments like: "This is only for benchmarking. The guy who wrote this file hasn't touched C since college. Please don't use this code in production."

----------
assignee:  -> christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Sat Jan 11 08:42:38 2020
From: report at bugs.python.org (Aurora)
Date: Sat, 11 Jan 2020 13:42:38 +0000
Subject: [issue39304] Don't accept a negative number for the count argument in
 str.replace(old, new[, count])
Message-ID: <1578750158.45.0.245853814213.issue39304@roundup.psfhosted.org>


New submission from Aurora <auroralanes at pm.me>:

It's meaningless for the count argument to have a negative value, since there's no such thing as negative count for something.

----------
components: Library (Lib)
messages: 359795
nosy: opensource-assist
priority: normal
severity: normal
status: open
title: Don't accept a negative number for the count argument in str.replace(old, new[,count])
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39304>
_______________________________________

From report at bugs.python.org  Sat Jan 11 09:06:33 2020
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 11 Jan 2020 14:06:33 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1578751593.68.0.718003820723.issue39298@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

For what it's worth, I spent some time producing clean benchmarks.  All these were run on the same laptop, and all pre-load the same file (406668786 bytes) and run one update() on the whole thing to minimize overhead.  K12 and BLAKE3 are using a hand-written C driver, and compiled with both gcc and clang; all the rest of the algorithms are from hashlib.new, python3 configured with --enable-optimizations and compiled with gcc.  K12 and BLAKE3 support several SIMD extensions; this laptop only has AVX2 (no AVX512).  All these numbers are the best of 3.  All tests were run in a single thread.

-----------------+----------+----------+----+-----------------------
   hash algorithm|elapsed s |mb/sec    |size|hash
-----------------+----------+----------+----+-----------------------
      K12-Haswell 0.176949   2298224495  64  24693954fa0dfb059f99...
K12-Haswell-clang 0.181968   2234841926  64  24693954fa0dfb059f99...
BLAKE3-AVX2-clang 0.250482   1623547723  64  30149a073eab69f76583...
      BLAKE3-AVX2 0.256845   1583326242  64  30149a073eab69f76583...
              md4 0.37684668 1079135924  32  d8a66422a4f0ae430317...
             sha1 0.46739069  870083193  40  a7488d7045591450ded9...
        K12-clang 0.498058    816509323  64  24693954fa0dfb059f99...
           BLAKE3 0.561470    724292378  64  30149a073eab69f76583...
              K12 0.569490    714093306  64  24693954fa0dfb059f99...
     BLAKE3-clang 0.573743    708800001  64  30149a073eab69f76583...
          blake2b 0.58276098  697831191 128  809ca44337af39792f8f...
              md5 0.59936016  678504863  32  306d7de4d1622384b976...
           sha384 0.64208886  633352818  96  b107ce5d086e9757efa7...
       sha512_224 0.66094102  615287556  56  90931762b9e553bd07f3...
       sha512_256 0.66465768  611846969  64  27b03aacdfbde1c2628e...
           sha512 0.6776549   600111921 128  f0af29e2019a6094365b...
          blake2s 0.86828375  468359318  64  02bee0661cd88aa2be15...
           sha256 0.97720436  416155312  64  48b5243cfcd90d84cd3f...
           sha224 1.0255457   396538907  56  10fb56b87724d59761c6...
        shake_128 1.0895037   373260576  32  2ec12727ac9d59c2e842...
         md5-sha1 1.1171806   364013470  72  306d7de4d1622384b976...
         sha3_224 1.2059123   337229156  56  93eaf083ca3a9b348e14...
        shake_256 1.3039152   311882857  64  b92538fd701791db8c1b...
         sha3_256 1.3417314   303092540  64  69354bf585f21c567f1e...
        ripemd160 1.4846368   273918025  40  30f2fe48fec404990264...
         sha3_384 1.7710776   229616579  96  61af0469534633003d3b...
              sm3 1.8384831   221198006  64  1075d29c75b06cb0af3e...
         sha3_512 2.4839673   163717444 128  c7c250e79844d8dc856e...

If I can't have BLAKE3, I'm definitely switching to BLAKE2 ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Sat Jan 11 10:02:37 2020
From: report at bugs.python.org (Batuhan)
Date: Sat, 11 Jan 2020 15:02:37 +0000
Subject: [issue21498] configparser accepts keys beginning with comment_chars
 when writing
In-Reply-To: <1399992449.17.0.699994077825.issue21498@psf.upfronthosting.co.za>
Message-ID: <1578754957.08.0.836443935131.issue21498@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Any update on this? Discussion over Python-Dev looks like finished without a consensus/resolution.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21498>
_______________________________________

From report at bugs.python.org  Sat Jan 11 10:04:41 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 11 Jan 2020 15:04:41 +0000
Subject: [issue39304] Don't accept a negative number for the count argument in
 str.replace(old, new[, count])
In-Reply-To: <1578750158.45.0.245853814213.issue39304@roundup.psfhosted.org>
Message-ID: <1578755081.96.0.166235699198.issue39304@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

negative value is an implementation detail where count < 0 is similar to replace all [0]. See also issue5416

[0] https://github.com/python/cpython/blob/43682f1e39a3c61f0e8a638b887bcdcbfef766c5/Objects/unicodeobject.c#L10578

----------
nosy: +rhettinger, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39304>
_______________________________________

From report at bugs.python.org  Sat Jan 11 10:07:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Jan 2020 15:07:58 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578755278.74.0.35462702034.issue39259@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 5d978a2e73e9ad934bcd260ae0a0db5cd0ca27d0 by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-39259: nntplib.NNTP/NNTP_SSL refactoring (GH-17939)
https://github.com/python/cpython/commit/5d978a2e73e9ad934bcd260ae0a0db5cd0ca27d0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Sat Jan 11 10:35:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Jan 2020 15:35:26 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578756926.28.0.974014774107.issue39288@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

PR 17937 is ready to be reviewed. The tests passed on the regular CIs and buildbots: good.

> That last assumes you want -0 and +0 to act differently

It is the case: I wrote an unit test checking exactly that, and it works as expected on all platforms (Windows, macOS, Linux, Intel, PPC, etc.).

> `nextafter()` is too widely implemented to fight against, despite the sucky name ;-)

nexttoward name is less ambiguous, but as you all said: "nextafter" name is way more popular. Honestly, it's not that hard to infer that the function can go "up" or "down" because it has a second parameter. If it's not obvious enough, maybe we can enhance the documentation.

--

About Wikipedia, the following articles are interesting for the ones like me who don't fully understand IEEE 754, rounding mode, etc.

* https://en.wikipedia.org/wiki/Unit_in_the_last_place
* https://en.wikipedia.org/wiki/Machine_epsilon
* https://en.wikipedia.org/wiki/IEEE_754

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sat Jan 11 10:37:34 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 11 Jan 2020 15:37:34 +0000
Subject: [issue39297] Synchronize importlib.metadata with importlib_metadata
 1.4
In-Reply-To: <1578704942.47.0.915059602595.issue39297@roundup.psfhosted.org>
Message-ID: <1578757054.16.0.359828123332.issue39297@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 136735c1a2efb320e4cbb64b40f1191228745b39 by Jason R. Coombs in branch 'master':
bpo-39297: Update for importlib_metadata 1.4.  (GH-17947)
https://github.com/python/cpython/commit/136735c1a2efb320e4cbb64b40f1191228745b39


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39297>
_______________________________________

From report at bugs.python.org  Sat Jan 11 10:37:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Jan 2020 15:37:52 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578757072.21.0.617970428968.issue39288@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh, I forgot to also give the nextafer() link to the POSIX standard:
https://pubs.opengroup.org/onlinepubs/009695399/functions/nextafter.html

It mentions for example "If x== y, y (of the type x) shall be returned" and "If x or y is NaN, a NaN shall be returned". It's good to know that it's specified ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sat Jan 11 10:38:00 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 11 Jan 2020 15:38:00 +0000
Subject: [issue39297] Synchronize importlib.metadata with importlib_metadata
 1.4
In-Reply-To: <1578704942.47.0.915059602595.issue39297@roundup.psfhosted.org>
Message-ID: <1578757080.63.0.595495321907.issue39297@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17361
pull_request: https://github.com/python/cpython/pull/17952

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39297>
_______________________________________

From report at bugs.python.org  Sat Jan 11 10:52:28 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 11 Jan 2020 15:52:28 +0000
Subject: [issue39305] Merge nntplib._NNTPBase and nntplib.NNTP
Message-ID: <1578757948.77.0.383613154988.issue39305@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

See: https://github.com/python/cpython/pull/17939#pullrequestreview-341290152

There was partial refactoring through PR 17939.
I and Victor think that nntplib._NNTPBase can be removed by merging nntplib._NNTPBase and nntplib.NNTP.

The only care point would be rewriting unit testing code which depends on nntplib._NNTPBase.

----------
components: Library (Lib)
messages: 359803
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: Merge nntplib._NNTPBase and nntplib.NNTP
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39305>
_______________________________________

From report at bugs.python.org  Sat Jan 11 10:57:04 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 11 Jan 2020 15:57:04 +0000
Subject: [issue39297] Synchronize importlib.metadata with importlib_metadata
 1.4
In-Reply-To: <1578704942.47.0.915059602595.issue39297@roundup.psfhosted.org>
Message-ID: <1578758224.14.0.474374721267.issue39297@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset 98b1c0c7ac7c80aac8bce8648fe14b55abeb382a by Jason R. Coombs (Miss Islington (bot)) in branch '3.8':
bpo-39297: Update for importlib_metadata 1.4.  (GH-17947) (GH-17952)
https://github.com/python/cpython/commit/98b1c0c7ac7c80aac8bce8648fe14b55abeb382a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39297>
_______________________________________

From report at bugs.python.org  Sat Jan 11 10:57:54 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 11 Jan 2020 15:57:54 +0000
Subject: [issue39304] Don't accept a negative number for the count argument in
 str.replace(old, new[, count])
In-Reply-To: <1578750158.45.0.245853814213.issue39304@roundup.psfhosted.org>
Message-ID: <1578758274.27.0.45428107863.issue39304@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This behaviour that goes all the way back to Python 1.5, if not older, before strings even had methods:

    [steve at ando ~]$ python1.5
    Python 1.5.2 (#1, Aug 27 2012, 09:09:18)  [GCC 4.1.2 20080704 
    (Red Hat 4.1.2-52)] on linux2
    Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
    >>> import string
    >>> string.replace("abacadaeaf", "a", "Z", -1)
    'ZbZcZdZeZf'


Hiding the fact that str.replace treats negative values as "replace all" just causes confusion, as people wrongly jump to the conclusion that it is a bug.

It's not a bug, it is a useful feature and it has been in the language for over 20 years. VB.Net has the same feature:

https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualbasic.strings.replace?view=netframework-4.8

Let's just document it as intentional and be done with it.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39304>
_______________________________________

From report at bugs.python.org  Sat Jan 11 11:30:21 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 11 Jan 2020 16:30:21 +0000
Subject: [issue39296] Windows register keys
In-Reply-To: <1578695287.77.0.549625073253.issue39296@roundup.psfhosted.org>
Message-ID: <1578760221.07.0.962871865928.issue39296@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Have you read PEP 514? Does that help?

If not, can you provide specific suggestions in terms of that standard to help us understand what you are suggesting?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39296>
_______________________________________

From report at bugs.python.org  Sat Jan 11 11:34:48 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 11 Jan 2020 16:34:48 +0000
Subject: [issue39297] Synchronize importlib.metadata with importlib_metadata
 1.4
In-Reply-To: <1578704942.47.0.915059602595.issue39297@roundup.psfhosted.org>
Message-ID: <1578760488.53.0.140093606904.issue39297@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39297>
_______________________________________

From report at bugs.python.org  Sat Jan 11 11:47:32 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 11 Jan 2020 16:47:32 +0000
Subject: [issue39304] Don't accept a negative number for the count argument in
 str.replace(old, new[, count])
In-Reply-To: <1578750158.45.0.245853814213.issue39304@roundup.psfhosted.org>
Message-ID: <1578761252.27.0.565633406639.issue39304@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Sorry, I disagree that this is a mere implementation detail. The term "implementation detail" normally implies behaviour which occurs *by accident* due to the specific implementation, rather than being intentionally chosen.

A good example is early versions of list.sort(), which was stable for small lists only because the implementation happened to use insertion sort for small lists. Insertion sort wasn't chosen because it was stable; had the implementation changed to another sort, the behaviour would have changed. (Later on, the implementation did change, and stability became a documented and guaranteed feature.)

This is not what is happening here. The behaviour of for negative count doesn't "just happen by accident" due to other, unrelated, choices. It happens because the code intentionally tests for a negative count and replaces it with the maximum value possible:

    if (maxcount < 0)
        maxcount = PY_SSIZE_T_MAX;


and it is documented in the C source code as a comment to argument clinic:

    count: Py_ssize_t = -1
        Maximum number of occurrences to replace.
        -1 (the default value) means replace all occurrences.


https://github.com/python/cpython/blob/43682f1e39a3c61f0e8a638b887bcdcbfef766c5/Objects/unicodeobject.c#L12682


Some more evidence that this is intentional behaviour: in test_string.py, there are various tests that -1 behaves the same as sys.maxsize, e.g.:

        EQ("ReyKKjaviKK", "Reykjavik", "replace", "k", "KK", -1)
        EQ("ReyKKjaviKK", "Reykjavik", "replace", "k", "KK", sys.maxsize)


That's not an isolated test, there are many of them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39304>
_______________________________________

From report at bugs.python.org  Sat Jan 11 11:48:52 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 11 Jan 2020 16:48:52 +0000
Subject: [issue39304] Don't accept a negative number for the count argument in
 str.replace(old, new[, count])
In-Reply-To: <1578750158.45.0.245853814213.issue39304@roundup.psfhosted.org>
Message-ID: <1578761332.6.0.556200451253.issue39304@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Oops, I meant Lib/test/string_tests.py not "test_string.py".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39304>
_______________________________________

From report at bugs.python.org  Sat Jan 11 11:52:24 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 11 Jan 2020 16:52:24 +0000
Subject: [issue39304] Don't accept a negative number for the count argument in
 str.replace(old, new[, count])
In-Reply-To: <1578750158.45.0.245853814213.issue39304@roundup.psfhosted.org>
Message-ID: <1578761544.45.0.556731498035.issue39304@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the details. I looked into the tests for this behavior too and agree it's a tested behavior. issue5416 already had similar discussion and the documentation was committed to be later reverted upon Raymond's suggestion. So I will leave it to him.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39304>
_______________________________________

From report at bugs.python.org  Sat Jan 11 12:00:33 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 11 Jan 2020 17:00:33 +0000
Subject: [issue39299] Improve test coverage for mimetypes module
In-Reply-To: <1578722796.76.0.475900715527.issue39299@roundup.psfhosted.org>
Message-ID: <1578762033.82.0.792571395143.issue39299@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

With the proposed PR the coverage [0] stands at 80% with Windows tests for registry not covered as part of the coverage report. The tests also now use tearDownModule to restore the value of mimetypes.knownfiles which was being accidentally set empty for other tests too as part of the test setup and not restored properly.

[0] https://codecov.io/gh/python/cpython/src/b80c9c384e744788a09176f6f894ea8495e19d6a/Lib/mimetypes.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39299>
_______________________________________

From report at bugs.python.org  Sat Jan 11 12:10:04 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 11 Jan 2020 17:10:04 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578762604.64.0.211049093405.issue39288@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

"nextafter" is fine with me. I just wanted to make sure that we'd considered the options, and weren't choosing nextafter simply because it's the easiest thing to implement.

[Victor]

> It mentions for example "If x== y, y (of the type x) shall be returned" and "If x or y is NaN, a NaN shall be returned". It's good to know that it's specified ;-)

Agreed; it would be good to make sure that we have tests for the behaviour matching the spec, particularly with respect to signed zeros: the first clause here implies nextafter(0.0, -0.0) is -0.0, while nextafter(-0.0, 0.0) is 0.0. I'd also recommend adding tests for nextafter(smallest_normal, 0.0), nextafter(largest_normal, inf), nextafter(inf, 0), and the like. 

The C standard isn't 100% clear on what nextafter(-0.0, inf) should be: it could be argued that the "next" representable float after -0.0 in the direction of infinity is 0.0. But IEEE 754 is explicit that nextUp(?0) is the smallest positive subnormal, and we should have a test for that, too.

Making the second argument optional sounds reasonable to me, but doesn't necessarily have to happen in the existing PR; we can always add that option later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sat Jan 11 12:24:52 2020
From: report at bugs.python.org (kernc)
Date: Sat, 11 Jan 2020 17:24:52 +0000
Subject: [issue27069] webbrowser creates zombi processes in the background mode
In-Reply-To: <1463746997.46.0.620771266968.issue27069@psf.upfronthosting.co.za>
Message-ID: <1578763492.79.0.291293172621.issue27069@roundup.psfhosted.org>


Change by kernc <kerncece at gmail.com>:


----------
nosy: +kernc
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27069>
_______________________________________

From report at bugs.python.org  Sat Jan 11 12:28:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Jan 2020 17:28:40 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578763720.24.0.746643464734.issue39288@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Mark:
> Making the second argument optional sounds reasonable to me, but doesn't necessarily have to happen in the existing PR; we can always add that option later.

Do you mean nextafter(x, y=inf, /): toward positive infinity by default? I prefer to keep the second parameter mandatory, to make the direction more explicit. As Tim showed, it's easy to implement nextUp() on top of 
nextafter().


> "nextafter" is fine with me.

Good :-) It seems like everybody agrees on nextafter().


> it would be good to make sure that we have tests for the behaviour matching the spec, particularly with respect to signed zeros: the first clause here implies nextafter(0.0, -0.0) is -0.0, while nextafter(-0.0, 0.0) is 0.0.

I had a test for math.nextafter(+0.0, -0.0). I added a test for math.nextafter(-0.0, +0.0).


> I'd also recommend adding tests for nextafter(smallest_normal, 0.0), nextafter(largest_normal, inf), nextafter(inf, 0),

Done.


> and the like.

Feel free to suggest more tests on the PR.


> The C standard isn't 100% clear on what nextafter(-0.0, inf) should be

I added a test for it, for positive and negative zeros.


> But IEEE 754 is explicit that nextUp(?0) is the smallest positive subnormal

That's what I get.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sat Jan 11 12:30:37 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 11 Jan 2020 17:30:37 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578763837.4.0.334641339459.issue39288@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Steven]

> I know Wikipedia isn't a primary source, but it says IEEE 754 recommends nextafter(x, y).

Um. Then it sounds as though Wikipedia is out of date. Which page was this on?

IEEE 754-1985 did recommend nextafter, but only in Annex A, which is not strictly part of the standard. ("This Appendix is not a part of ANSI/IEEE Std 754-1985, IEEE Standard for Binary Floating-Point Arithmetic [...]")

IEEE 754-2008 (section 5.3.1) added nextUp and nextDown as required operations, and the text for those operations is word-for-word identical in the current IEEE 754-2019, save for "sNaNs" being spelled out as "signaling NaNs".

> My understanding of IEEE-754 is that the functionality is required, not the specific API. That is, it's not required to have literally two functions called "nextUp" and "nextDown", so long as you can get the next larger and next smaller float.

Agreed. It's not really spelled out in the standard exactly what "conformance" would mean, but I agree that providing nextafter should be sufficient if we want to claim that Python supports the nextUp and nextDown operations.

Not that Python makes any claim to conform with IEEE 754 anyway, but I think it's still a useful standard to consider when we're choosing what to do in the math module.

I guess if we *wanted* to claim strict conformance with IEEE 754 (which we don't, right now), we'd probably also want to add a note in the docs explaining how nextUp and nextDown are represented in terms of nextafter. But that seems a bit redundant to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sat Jan 11 12:33:44 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 11 Jan 2020 17:33:44 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578764024.34.0.586065785043.issue39288@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Do you mean nextafter(x, y=inf, /): toward positive infinity by default?

Yes; I believe that was what Steven was suggesting in the last part of msg359779. I don't have strong feelings either way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sat Jan 11 12:39:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 11 Jan 2020 17:39:18 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578764358.95.0.800498683374.issue39259@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1b335ae281631a12201fdec29b3c55d97166fc06 by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-39259: nntplib.NNTP/NNTP_SSL now reject timeout = 0 (GH-17936)
https://github.com/python/cpython/commit/1b335ae281631a12201fdec29b3c55d97166fc06


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Sat Jan 11 13:37:42 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 11 Jan 2020 18:37:42 +0000
Subject: [issue39301] Specification of bitshift on integers should clearly
 state floor division used
In-Reply-To: <1578725984.98.0.631488660974.issue39301@roundup.psfhosted.org>
Message-ID: <1578767862.78.0.93483714083.issue39301@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39301>
_______________________________________

From report at bugs.python.org  Sat Jan 11 13:46:06 2020
From: report at bugs.python.org (Batuhan)
Date: Sat, 11 Jan 2020 18:46:06 +0000
Subject: [issue23139] syntax diagram after EBNF description?
In-Reply-To: <1420019271.73.0.760663743856.issue23139@psf.upfronthosting.co.za>
Message-ID: <1578768366.53.0.0807706786261.issue23139@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

I am not sure but I suspect it would look to complex to a reader if all grammar visualized.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23139>
_______________________________________

From report at bugs.python.org  Sat Jan 11 14:10:47 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 11 Jan 2020 19:10:47 +0000
Subject: [issue39301] Specification of bitshift on integers should clearly
 state floor division used
In-Reply-To: <1578725984.98.0.631488660974.issue39301@roundup.psfhosted.org>
Message-ID: <1578769847.63.0.926714484706.issue39301@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Is the fix as simple as adding the word "floor" before "division" in the "equivalent to division by [...]" phrase?

> A right shift by n bits is equivalent to floor division by pow(2, n) without overflow check. 

This text was probably written before // was introduced; maybe we can rewrite in terms of //? "x >> n" should be identical to "x // pow(2, n)" for any nonnegative "n".

I confess that I've no idea what the "without overflow check" bit means, but I suspect it's no longer relevant post int/long-unification.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39301>
_______________________________________

From report at bugs.python.org  Sat Jan 11 14:28:37 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 11 Jan 2020 19:28:37 +0000
Subject: [issue39300] dataclasses non-default argument follows default argument
In-Reply-To: <1578723686.9.0.201746303828.issue39300@roundup.psfhosted.org>
Message-ID: <1578770917.01.0.768053978602.issue39300@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

> Ah, I see, so if I understand correctly the init method for the example given would become __init__(self, PARAM: int = 1, ARG: int) since the fields are kept in an ordered mapping

Correct.

----------
assignee:  -> eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39300>
_______________________________________

From report at bugs.python.org  Sat Jan 11 14:34:16 2020
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 11 Jan 2020 19:34:16 +0000
Subject: [issue39275] Traceback off by one line when
In-Reply-To: <1578576348.64.0.412986299263.issue39275@roundup.psfhosted.org>
Message-ID: <1578771256.17.0.0715547791513.issue39275@roundup.psfhosted.org>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

This is a duplicate of https://bugs.python.org/issue16482 -- closing it.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39275>
_______________________________________

From report at bugs.python.org  Sat Jan 11 14:41:48 2020
From: report at bugs.python.org (Hans Strijker)
Date: Sat, 11 Jan 2020 19:41:48 +0000
Subject: [issue39306] Lib/configparser.py - RawConfigParser.set does not pass
 non-truthy values through to Interpolation.before_set
Message-ID: <1578771708.17.0.449482349848.issue39306@roundup.psfhosted.org>


New submission from Hans Strijker <hans at stry.org>:

Method ```configparser.RawConfigParser.set()``` has optional parameter *value* with default value ```None``` resulting in the behavior that actually trying to set a config parameter to ```None``` will not be propagated to ```Interpolation.before_set()```. In fact, since it uses ```if value:``` and not ```if value is None:``` none of the non-truthy values will be passed through.

Suggested commit [8e008be](https://github.com/HStry/cpython/commit/8e008bea0cf6bd3c698b333fd39a383e124fe026) using already established ```_UNSET``` singleton, but that appears to break compatibility elsewhere.

----------
components: Library (Lib)
messages: 359820
nosy: Strijker, taleinat
priority: normal
pull_requests: 17362
severity: normal
status: open
title: Lib/configparser.py - RawConfigParser.set does not pass non-truthy values through to Interpolation.before_set
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/issue39306>
_______________________________________

From report at bugs.python.org  Sat Jan 11 15:13:33 2020
From: report at bugs.python.org (Alex Henrie)
Date: Sat, 11 Jan 2020 20:13:33 +0000
Subject: [issue39307] Memory leak in parsetok
Message-ID: <1578773613.93.0.403344641263.issue39307@roundup.psfhosted.org>


New submission from Alex Henrie <alexhenrie24 at gmail.com>:

The parsetok function currently contains the following code:

    if (!growable_comment_array_init(&type_ignores, 10)) {
        err_ret->error = E_NOMEM;
        PyTokenizer_Free(tok);
        return NULL;
    }

    if ((ps = PyParser_New(g, start)) == NULL) {
        err_ret->error = E_NOMEM;
        PyTokenizer_Free(tok);
        return NULL;
    }

If PyParser_New fails, there is a memory leak because growable_comment_array_deallocate is not called on type_ignores.

----------
components: Interpreter Core
messages: 359821
nosy: alex.henrie
priority: normal
severity: normal
status: open
title: Memory leak in parsetok
type: resource usage
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39307>
_______________________________________

From report at bugs.python.org  Sat Jan 11 15:15:27 2020
From: report at bugs.python.org (Alex Henrie)
Date: Sat, 11 Jan 2020 20:15:27 +0000
Subject: [issue39307] Memory leak in parsetok
In-Reply-To: <1578773613.93.0.403344641263.issue39307@roundup.psfhosted.org>
Message-ID: <1578773727.12.0.0449653134975.issue39307@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
keywords: +patch
pull_requests: +17363
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17953

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39307>
_______________________________________

From report at bugs.python.org  Sat Jan 11 16:30:44 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 11 Jan 2020 21:30:44 +0000
Subject: [issue31485] Tkinter widget.unbind(sequence,
 funcid) unbind all bindings
In-Reply-To: <1505483834.38.0.808110743528.issue31485@psf.upfronthosting.co.za>
Message-ID: <1578778244.85.0.379689456484.issue31485@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17364
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17954

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31485>
_______________________________________

From report at bugs.python.org  Sat Jan 11 18:35:15 2020
From: report at bugs.python.org (=?utf-8?q?Tomasz_Tr=C4=99bski?=)
Date: Sat, 11 Jan 2020 23:35:15 +0000
Subject: [issue39308] Literal[True] interpreted as Literal[1]
Message-ID: <1578785715.62.0.203170094807.issue39308@roundup.psfhosted.org>


New submission from Tomasz Tr?bski <kornicameister at gmail.com>:

Consider code (in attachment) that is being run on Python 3.9.
An expected output of such code ought to be:

(typing_extensions.Literal[1], typing_extensions.Literal[0]) (typing_extensions.Literal[True], typing_extensions.Literal[False])

However that's not the case. An output of the code, given that A is declared first, will be:

(typing.Literal[1], typing.Literal[0]) (typing.Literal[1], typing.Literal[0])

and if B is declared first we receive:

(typing.Literal[True], typing.Literal[False]) (typing.Literal[True], typing.Literal[False])

I believe a reason for that is having `bool` as subclass of `int` and consecutively having `typing._tp_cache` function that declares untyped cache. Indeed changing `cached = functools.lru_cache()(func)` to `cached = functools.lru_cache(typed=True)(func)` makes the linked code immune to A and B deceleration order.

----------
components: ctypes
files: scratch_1.py
messages: 359822
nosy: Tomasz Tr?bski
priority: normal
severity: normal
status: open
title: Literal[True] interpreted as Literal[1]
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file48835/scratch_1.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39308>
_______________________________________

From report at bugs.python.org  Sat Jan 11 18:36:57 2020
From: report at bugs.python.org (=?utf-8?q?Tomasz_Tr=C4=99bski?=)
Date: Sat, 11 Jan 2020 23:36:57 +0000
Subject: [issue39308] Literal declarations are not typed. Literal[True] can be
 Literal[1] if declared after latter.
In-Reply-To: <1578785715.62.0.203170094807.issue39308@roundup.psfhosted.org>
Message-ID: <1578785817.71.0.460311945646.issue39308@roundup.psfhosted.org>


Change by Tomasz Tr?bski <kornicameister at gmail.com>:


----------
title: Literal[True] interpreted as Literal[1] -> Literal declarations are not typed. Literal[True] can be Literal[1] if declared after latter.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39308>
_______________________________________

From report at bugs.python.org  Sat Jan 11 18:52:39 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 11 Jan 2020 23:52:39 +0000
Subject: [issue39308] Literal declarations are not typed. Literal[True] can be
 Literal[1] if declared after latter.
In-Reply-To: <1578785715.62.0.203170094807.issue39308@roundup.psfhosted.org>
Message-ID: <1578786759.91.0.897073962964.issue39308@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39308>
_______________________________________

From report at bugs.python.org  Sat Jan 11 18:54:26 2020
From: report at bugs.python.org (=?utf-8?q?Tomasz_Tr=C4=99bski?=)
Date: Sat, 11 Jan 2020 23:54:26 +0000
Subject: [issue39308] Literal declarations are not typed. Literal[True] can be
 Literal[1] if declared after latter.
In-Reply-To: <1578785715.62.0.203170094807.issue39308@roundup.psfhosted.org>
Message-ID: <1578786866.35.0.523604629507.issue39308@roundup.psfhosted.org>


Tomasz Tr?bski <kornicameister at gmail.com> added the comment:

Also happens in `3.8`, so right when `Literal` got moved to core `Python`.

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39308>
_______________________________________

From report at bugs.python.org  Sat Jan 11 19:38:14 2020
From: report at bugs.python.org (calebj)
Date: Sun, 12 Jan 2020 00:38:14 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1578789494.09.0.857125250611.issue39168@roundup.psfhosted.org>


Change by calebj <me at calebj.io>:


----------
nosy: +calebj

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Sat Jan 11 19:45:02 2020
From: report at bugs.python.org (Tony)
Date: Sun, 12 Jan 2020 00:45:02 +0000
Subject: [issue39296] Windows register keys
In-Reply-To: <1578760221.07.0.962871865928.issue39296@roundup.psfhosted.org>
Message-ID: <5e1a6c0a.1c69fb81.ed12.3a71@mx.google.com>


Tony <factoryx.code at gmail.com> added the comment:

Hello Steve,

I just red the PEP 514.
Thank you for pointing this out.
However, when installing the latest version (3.8.1), the multi-user install is registered under key 
?HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\? as the PEP describes.
The key ?HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Python\PythonCore\3.8-32?
Is a bit confusing, because since I know I have to search the registry for 32bit apps installed on a 64bit OS in ?..\WOW6432Node?,
the versionsuffix ?-32? is a bit overdone in my opinion because have to write extra code to extract the version number only, as you can see in the screenshot of the registry (See attachment).
The single user option however, is registered different. Here the key is not registered  like the multi-user option under key ?..\WOW6432Node?, but in key ?HKEY_CURRENT_USER\Software\? while I would expect the same as the Multi-user option: ?..\WOW6432Node?.
I hope I explained enough about this.

Greetings, Tony.

Van: Steve Dower
Verzonden: zaterdag 11 januari 2020 17:30
Aan: factoryx.code at gmail.com
Onderwerp: [issue39296] Windows register keys

Steve Dower <steve.dower at python.org> added the comment:

Have you read PEP 514? Does that help?

If not, can you provide specific suggestions in terms of that standard to help us understand what you are suggesting?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39296>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39296>
_______________________________________

From report at bugs.python.org  Sat Jan 11 19:48:42 2020
From: report at bugs.python.org (Tony)
Date: Sun, 12 Jan 2020 00:48:42 +0000
Subject: [issue39296] Windows register keys
In-Reply-To: <1578760221.07.0.962871865928.issue39296@roundup.psfhosted.org>
Message-ID: <5e1a6ce8.1c69fb81.b0886.2d86@mx.google.com>


Tony <factoryx.code at gmail.com> added the comment:

The attachment I forgot..

Greetings, Tony.

Van: Steve Dower
Verzonden: zaterdag 11 januari 2020 17:30
Aan: factoryx.code at gmail.com
Onderwerp: [issue39296] Windows register keys

Steve Dower <steve.dower at python.org> added the comment:

Have you read PEP 514? Does that help?

If not, can you provide specific suggestions in terms of that standard to help us understand what you are suggesting?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39296>
_______________________________________

----------
Added file: https://bugs.python.org/file48836/python-reg1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39296>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: python-reg1.jpg
Type: image/jpeg
Size: 10444 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20200112/ec42b255/attachment-0001.jpg>

From report at bugs.python.org  Sat Jan 11 19:50:52 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 00:50:52 +0000
Subject: [issue32524] Python 2.7 leaks a packages __init__.py module object on
 SyntaxError
In-Reply-To: <1515532370.23.0.467229070634.issue32524@psf.upfronthosting.co.za>
Message-ID: <1578790252.95.0.610942846392.issue32524@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32524>
_______________________________________

From report at bugs.python.org  Sat Jan 11 20:01:37 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 01:01:37 +0000
Subject: [issue27195] Crash when RawIOBase.write(b) evaluates b.format
In-Reply-To: <1464929981.41.0.2917772561.issue27195@psf.upfronthosting.co.za>
Message-ID: <1578790897.7.0.861107333442.issue27195@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27195>
_______________________________________

From report at bugs.python.org  Sat Jan 11 20:15:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jan 2020 01:15:50 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578791750.13.0.413495474944.issue39288@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 100fafcf20e8fc67cd8ef512074f9c0a253cb427 by Victor Stinner in branch 'master':
bpo-39288: Add math.nextafter(x, y) (GH-17937)
https://github.com/python/cpython/commit/100fafcf20e8fc67cd8ef512074f9c0a253cb427


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sat Jan 11 20:21:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jan 2020 01:21:08 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578792068.24.0.497209168578.issue39288@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I chose to make y mandatory in nextafter(x, y). Implement your own flavor if nextUp(x) if you want to omit y. I prefer to make y explicit, becauseit has been said in this discussion that "nextafter" name is ambiguous.

Thanks all for the constructive discussion. I merged my PR reviewed by Mark. Enjoy IEEE 754 and have fun with rounding!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sat Jan 11 20:35:11 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Jan 2020 01:35:11 +0000
Subject: [issue39304] Don't accept a negative number for the count argument in
 str.replace(old, new[, count])
In-Reply-To: <1578750158.45.0.245853814213.issue39304@roundup.psfhosted.org>
Message-ID: <1578792911.73.0.211467982076.issue39304@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39304>
_______________________________________

From report at bugs.python.org  Sat Jan 11 20:38:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 12 Jan 2020 01:38:46 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578793126.92.0.577635335091.issue39288@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I suggest "next_after" instead of "nextafter".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sat Jan 11 21:01:05 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 02:01:05 +0000
Subject: [issue32978] Issues with reading large float values in AIFC files
In-Reply-To: <1519923035.62.0.467229070634.issue32978@psf.upfronthosting.co.za>
Message-ID: <1578794465.75.0.865045161582.issue32978@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions: +Python 3.9 -Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32978>
_______________________________________

From report at bugs.python.org  Sat Jan 11 21:29:51 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 02:29:51 +0000
Subject: [issue33471] string format with 'n' failling with french locales
In-Reply-To: <1526124606.41.0.682650639539.issue33471@psf.upfronthosting.co.za>
Message-ID: <1578796191.35.0.664902861527.issue33471@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> float.__format__('n') fails with _PyUnicode_CheckConsistency assertion error for locales with non-ascii thousands separator

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33471>
_______________________________________

From report at bugs.python.org  Sat Jan 11 21:40:48 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 02:40:48 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1578796848.04.0.71319389262.issue34732@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Updating version and adding some people to the nosy list to review the two suggested pull requests for this issue.  Thanks!

----------
nosy: +barry, cheryl.sabella, taleinat, twouters
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Sat Jan 11 22:11:46 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 12 Jan 2020 03:11:46 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1578798706.43.0.902760862073.issue1635741@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

FWIW, i counted the difference of each file's refs after `Py_Finalize()`.

[('Objects/dictobject.c', 21434), ('Python/marshal.c', 8135), ('Objects/codeobject.c', 6245), ('Objects/listobject.c', 6037), ('Objects/tupleobject.c', 4169), ('Objects/boolobject.c', 2433), ('Objects/object.c', 2364), ('Objects/unicodeobject.c', 1541), ('Objects/longobject.c', 1387), ('Objects/funcobject.c', 528), ('Objects/classobject.c', 528), ('Objects/abstract.c', 463), ('Python/structmember.c', 369), ('./Include/objimpl.h', 277), ('Objects/stringlib/partition.h', 273), ('Python/import.c', 259), ('Python/codecs.c', 197), ('./Modules/signalmodule.c', 61), ('./Modules/_threadmodule.c', 59), ('Objects/exceptions.c', 15), ('Objects/bytesobject.c', 5), ('./Modules/_weakref.c', 4), ('Python/_warnings.c', 3), ('./Modules/timemodule.c', 1), ('./Modules/_codecsmodule.c', 1), ('Objects/bytearrayobject.c', 1), ('Python/compile.c', 1), ('Objects/sliceobject.c', 0), ('Objects/memoryobject.c', 0), ('Python/context.c', -1), ('Objects/clinic/longobject.c.h', -1), ('Objects/enumobject.c', -1), ('Modules/gcmodule.c', -1), ('Objects/namespaceobject.c', -1), ('Objects/stringlib/unicode_format.h', -2), ('Objects/rangeobject.c', -3), ('Python/pystate.c', -4), ('Objects/fileobject.c', -14), ('./Modules/_io/clinic/bufferedio.c.h', -17), ('./Modules/_io/iobase.c', -21), ('Python/modsupport.c', -28), ('./Modules/_io/fileio.c', -28), ('Python/pylifecycle.c', -37), ('./Modules/_io/textio.c', -39), ('Objects/genobject.c', -53), ('Objects/weakrefobject.c', -54), ('./Modules/_io/bufferedio.c', -56), ('./Python/sysmodule.c', -68), ('./Modules/_io/_iomodule.c', -82), ('Python/errors.c', -90), ('Objects/descrobject.c', -110), ('Objects/structseq.c', -113), ('Python/bltinmodule.c', -118), ('Objects/setobject.c', -339), ('Objects/moduleobject.c', -454), ('./Modules/posixmodule.c', -614), ('./Modules/_abc.c', -664), ('Objects/call.c', -755), ('Objects/typeobject.c', -2035), ('Objects/frameobject.c', -6538), ('Python/ceval.c', -7857), ('./Include/object.h', -48292)]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sun Jan 12 00:10:39 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 12 Jan 2020 05:10:39 +0000
Subject: [issue39308] Literal[True] prints as Literal[1] in some cases
In-Reply-To: <1578785715.62.0.203170094807.issue39308@roundup.psfhosted.org>
Message-ID: <1578805839.02.0.649837539281.issue39308@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

No need to open the attachment -- a simpler repro is:

>>> from typing import Literal
>>> Literal[1]
typing.Literal[1]
>>> Literal[True]
typing.Literal[1]
>>> 

However, in a fresh session

>>> from typing import Literal
>>> Literal[True]
typing.Literal[True]
>>> 

This must be because there's a cache in typing.py that use == but doesn't check the type. We can demonstrate that this is the case using a similar equivalence between 2.0 and 2:

>>> Literal[2.0]
typing.Literal[2.0]
>>> Literal[2]
typing.Literal[2.0]
>>> 

It looks like the function _tp_cache() is the culprit -- it uses functools.lru_cache() which apparently uses simple equality.

def _tp_cache(func):
    """..."""
    cached = functools.lru_cache()(func)
    _cleanups.append(cached.cache_clear)

    @functools.wraps(func)
    def inner(*args, **kwds):
        try:
            return cached(*args, **kwds)
        except TypeError:
            pass  # All real errors (not unhashable args) are raised below.
        return func(*args, **kwds)
    return inner

Here's a confusing demo:

>> @functools.lru_cache()
... def f(a): return a
... 
>>> f(1)
1
>>> f(True)
True
>>> f(1)
1
>>> f(1.0)
True
>>> 

(Confusing because it distinguishes between 1 and True, unlike Literal, but it then maps 1.0 to True.)

However a possible fix might be to add typed=True to the functools.lru_cache() call in typing.py, which should have the desired effect (not tested).

----------
title: Literal declarations are not typed. Literal[True] can be Literal[1] if declared after latter. -> Literal[True] prints as Literal[1] in some cases

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39308>
_______________________________________

From report at bugs.python.org  Sun Jan 12 00:12:25 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Jan 2020 05:12:25 +0000
Subject: [issue39301] Specification of bitshift on integers should clearly
 state floor division used
In-Reply-To: <1578725984.98.0.631488660974.issue39301@roundup.psfhosted.org>
Message-ID: <1578805945.9.0.407717251437.issue39301@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Aye, adding "floor" to the existing footnote would be the minimal fix. I'm just wondering whether it's also worth stating that this means that positive integers saturate at zero, while negative integers saturate at -1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39301>
_______________________________________

From report at bugs.python.org  Sun Jan 12 01:15:24 2020
From: report at bugs.python.org (Sfjwlejfawnfsfjwlejfawnf)
Date: Sun, 12 Jan 2020 06:15:24 +0000
Subject: [issue39309] Please delete my account
Message-ID: <1578809724.37.0.611407008489.issue39309@roundup.psfhosted.org>


Change by Sfjwlejfawnfsfjwlejfawnf <d23603 at urhen.com>:


----------
nosy: sfjwlejfawnf
priority: normal
severity: normal
status: open
title: Please delete my account

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39309>
_______________________________________

From report at bugs.python.org  Sun Jan 12 01:16:00 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Jan 2020 06:16:00 +0000
Subject: [issue39292] syslog constants behind rfc
In-Reply-To: <1578678875.77.0.925015529037.issue39292@roundup.psfhosted.org>
Message-ID: <1578809760.87.0.104964316737.issue39292@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39292>
_______________________________________

From report at bugs.python.org  Sun Jan 12 01:51:16 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 12 Jan 2020 06:51:16 +0000
Subject: [issue36351] the ipv6type variable in configure.ac may be set
 incorrectly when cross-compiling
In-Reply-To: <1552925433.25.0.962523188847.issue36351@roundup.psfhosted.org>
Message-ID: <1578811876.37.0.00612527074798.issue36351@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +17365
pull_request: https://github.com/python/cpython/pull/17956

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36351>
_______________________________________

From report at bugs.python.org  Sun Jan 12 01:52:37 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 12 Jan 2020 06:52:37 +0000
Subject: [issue36351] the ipv6type variable in configure.ac may be set
 incorrectly when cross-compiling
In-Reply-To: <1552925433.25.0.962523188847.issue36351@roundup.psfhosted.org>
Message-ID: <1578811957.81.0.142225245457.issue36351@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36351>
_______________________________________

From report at bugs.python.org  Sun Jan 12 01:54:58 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 12 Jan 2020 06:54:58 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1578812098.63.0.868762881826.issue35561@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

Thank you, Victor, for the comments.  I will update PR 17782.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35561>
_______________________________________

From report at bugs.python.org  Sun Jan 12 02:37:48 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 12 Jan 2020 07:37:48 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578814668.83.0.357088245886.issue39259@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17366
pull_request: https://github.com/python/cpython/pull/17958

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Sun Jan 12 02:44:02 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Jan 2020 07:44:02 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1578815042.64.0.55451552843.issue16575@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It seems that notwithstanding the issues identified in the original bug report, calls by value of structs containing unions are being used out there in the wild. Examples:

The comtypes library (Windows):
https://github.com/python/cpython/pull/16799#issuecomment-573318591

The ctypesgen library, which is used by other projects across platforms:
https://github.com/davidjamesca/ctypesgen/issues/77

Linux examples:
https://github.com/waveform80/picamera/issues/604
https://github.com/hcpl/xkbgroup/issues/15
https://github.com/enkore/i3pystatus/issues/771

So, it would seem that the simplest course of action is to disable the checks for now. The checks will be commented out and this issue and the related issue bpo-16576 will be reopened.

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Sun Jan 12 02:46:05 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Jan 2020 07:46:05 +0000
Subject: [issue16576] ctypes: structure with bitfields as argument
In-Reply-To: <1354164812.19.0.708202681719.issue16576@psf.upfronthosting.co.za>
Message-ID: <1578815165.52.0.330698319892.issue16576@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The issue is being reopened, see this comment on bpo-16575:

https://bugs.python.org/msg359834

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16576>
_______________________________________

From report at bugs.python.org  Sun Jan 12 03:25:08 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 12 Jan 2020 08:25:08 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578817508.69.0.238848788622.issue39259@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17367
pull_request: https://github.com/python/cpython/pull/17959

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Sun Jan 12 03:27:48 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Jan 2020 08:27:48 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1578817668.81.0.928703655297.issue16575@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests: +17368
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17960

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Sun Jan 12 03:30:24 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Jan 2020 08:30:24 +0000
Subject: [issue26628] Undefined behavior calling C functions with ctypes.Union
 arguments
In-Reply-To: <1458766336.13.0.0388960184699.issue26628@psf.upfronthosting.co.za>
Message-ID: <1578817824.94.0.818647323619.issue26628@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
dependencies: +ctypes: unions as arguments
resolution: fixed -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26628>
_______________________________________

From report at bugs.python.org  Sun Jan 12 03:54:05 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Jan 2020 08:54:05 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1578819245.94.0.457560878707.issue16575@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset c12440c371025bea9c3bfb94945f006c486c2c01 by Vinay Sajip in branch 'master':
bpo-16575: Disabled checks for union types being passed by value. (GH-17960)
https://github.com/python/cpython/commit/c12440c371025bea9c3bfb94945f006c486c2c01


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Sun Jan 12 04:04:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jan 2020 09:04:36 +0000
Subject: [issue12159] Integer Overflow in __len__
In-Reply-To: <1306160642.73.0.477719318482.issue12159@psf.upfronthosting.co.za>
Message-ID: <1578819876.09.0.103170096143.issue12159@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d7c7adde003ddca5cbe4fc47cf09464ab95a066e by Victor Stinner (Zac Hatfield-Dodds) in branch 'master':
bpo-12159: Document sys.maxsize limit in len() function reference (GH-17934)
https://github.com/python/cpython/commit/d7c7adde003ddca5cbe4fc47cf09464ab95a066e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12159>
_______________________________________

From report at bugs.python.org  Sun Jan 12 04:23:37 2020
From: report at bugs.python.org (Christoph Reiter)
Date: Sun, 12 Jan 2020 09:23:37 +0000
Subject: [issue38883] Path.home() should ignore HOME env var like
 os.path.expanduser()
In-Reply-To: <1574361912.09.0.220955326522.issue38883@roundup.psfhosted.org>
Message-ID: <1578821017.69.0.181127827309.issue38883@roundup.psfhosted.org>


Change by Christoph Reiter <reiter.christoph at gmail.com>:


----------
keywords: +patch
pull_requests: +17369
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17961

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38883>
_______________________________________

From report at bugs.python.org  Sun Jan 12 04:23:37 2020
From: report at bugs.python.org (Christoph Reiter)
Date: Sun, 12 Jan 2020 09:23:37 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1578821017.84.0.564450931006.issue36264@roundup.psfhosted.org>


Change by Christoph Reiter <reiter.christoph at gmail.com>:


----------
pull_requests: +17370
pull_request: https://github.com/python/cpython/pull/17961

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Sun Jan 12 04:34:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jan 2020 09:34:51 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578821691.23.0.814370238908.issue39288@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17371
pull_request: https://github.com/python/cpython/pull/17962

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sun Jan 12 05:32:35 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 12 Jan 2020 10:32:35 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578825155.53.0.864506245522.issue39288@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I suggest "next_after" instead of "nextafter".

"nextafter" gives us consistency with C, with NumPy and with other compound names in the math module ("isnan", "isclose", "copysign"). My own brain doesn't perceive either of "nextafter" or "next_after" as more readable than the other.

What's the argument for "next_after"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sun Jan 12 06:03:05 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 11:03:05 +0000
Subject: [issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks
 threads
In-Reply-To: <1570056781.39.0.894014377654.issue38356@roundup.psfhosted.org>
Message-ID: <1578826985.38.0.169855898252.issue38356@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0ca7cc7fc0518c24dc9b78c38418e6064e64f148 by Miss Islington (bot) (Kyle Stanley) in branch 'master':
bpo-38356: Fix ThreadedChildWatcher thread leak in test_asyncio (GH-16552)
https://github.com/python/cpython/commit/0ca7cc7fc0518c24dc9b78c38418e6064e64f148


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38356>
_______________________________________

From report at bugs.python.org  Sun Jan 12 06:03:19 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 11:03:19 +0000
Subject: [issue39233] glossary entry for parameter out-of-date for
 positional-only parameters
In-Reply-To: <1578336890.4.0.142758348692.issue39233@roundup.psfhosted.org>
Message-ID: <1578826999.12.0.535471042717.issue39233@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a240f0545653d961c67c1eb1597cb70b67f4e5f1 by Miss Islington (bot) in branch '3.8':
bpo-39233: Update positional-only section in the glossary (GH-17874)
https://github.com/python/cpython/commit/a240f0545653d961c67c1eb1597cb70b67f4e5f1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39233>
_______________________________________

From report at bugs.python.org  Sun Jan 12 06:03:32 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 11:03:32 +0000
Subject: [issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks
 threads
In-Reply-To: <1570056781.39.0.894014377654.issue38356@roundup.psfhosted.org>
Message-ID: <1578827012.66.0.679321692234.issue38356@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17372
pull_request: https://github.com/python/cpython/pull/17963

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38356>
_______________________________________

From report at bugs.python.org  Sun Jan 12 06:07:48 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 12 Jan 2020 11:07:48 +0000
Subject: [issue39233] glossary entry for parameter out-of-date for
 positional-only parameters
In-Reply-To: <1578336890.4.0.142758348692.issue39233@roundup.psfhosted.org>
Message-ID: <1578827268.47.0.646971288159.issue39233@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Pablo: thanks for the quick fix!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39233>
_______________________________________

From report at bugs.python.org  Sun Jan 12 06:21:03 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 11:21:03 +0000
Subject: [issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks
 threads
In-Reply-To: <1570056781.39.0.894014377654.issue38356@roundup.psfhosted.org>
Message-ID: <1578828063.83.0.639708074174.issue38356@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 33dd75a28fe2ec6e85c5d3b315b5a9d4cf0652db by Miss Islington (bot) in branch '3.8':
bpo-38356: Fix ThreadedChildWatcher thread leak in test_asyncio (GH-16552)
https://github.com/python/cpython/commit/33dd75a28fe2ec6e85c5d3b315b5a9d4cf0652db


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38356>
_______________________________________

From report at bugs.python.org  Sun Jan 12 06:22:31 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 12 Jan 2020 11:22:31 +0000
Subject: [issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks
 threads
In-Reply-To: <1570056781.39.0.894014377654.issue38356@roundup.psfhosted.org>
Message-ID: <1578828151.44.0.104227287061.issue38356@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I hope it is fixed now.
Thanks, Kyle!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38356>
_______________________________________

From report at bugs.python.org  Sun Jan 12 06:22:37 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 12 Jan 2020 11:22:37 +0000
Subject: [issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks
 threads
In-Reply-To: <1570056781.39.0.894014377654.issue38356@roundup.psfhosted.org>
Message-ID: <1578828157.6.0.0163362927977.issue38356@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38356>
_______________________________________

From report at bugs.python.org  Sun Jan 12 06:23:28 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 11:23:28 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1578828208.51.0.599845913491.issue16575@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17373
pull_request: https://github.com/python/cpython/pull/17964

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Sun Jan 12 06:41:11 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Jan 2020 11:41:11 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1578829271.03.0.739407080768.issue16575@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset eb9ba2f66df2195a9c6295e73ab3d545a1445f05 by Vinay Sajip (Miss Islington (bot)) in branch '3.8':
bpo-16575: Disabled checks for union types being passed by value. (GH-17960) (GH-17964)
https://github.com/python/cpython/commit/eb9ba2f66df2195a9c6295e73ab3d545a1445f05


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Sun Jan 12 06:57:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jan 2020 11:57:51 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578830271.31.0.161407024166.issue39288@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 54cfbb2feee1f7328c3d6799ec3734b00824b555 by Victor Stinner in branch 'master':
bpo-39288: Add examples to math.nextafter() documentation (GH-17962)
https://github.com/python/cpython/commit/54cfbb2feee1f7328c3d6799ec3734b00824b555


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sun Jan 12 07:33:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jan 2020 12:33:34 +0000
Subject: [issue39310] Add math.ulp(x)
Message-ID: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

In bpo-39288, I added math.nextafter(x, y) function. I propose to now add math.ulp() companion function.

Examples from tests of my PR:

    self.assertEqual(math.ulp(1.0), sys.float_info.epsilon)
    self.assertEqual(math.ulp(2.0 ** 52), 1.0)
    self.assertEqual(math.ulp(2.0 ** 53), 2.0)
    self.assertEqual(math.ulp(2.0 ** 64), 4096.0)

Unit in the last place:

* https://en.wikipedia.org/wiki/Unit_in_the_last_place
* Java provides a java.lang.Math.ulp(x) function: https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#ulp-double-

In numpy, I found two references to ULP:

* numpy.testing.assert_array_almost_equal_nulp:
https://docs.scipy.org/doc/numpy-1.13.0/reference/generated/numpy.testing.assert_array_almost_equal_nulp.html

* numpy.testing.assert_array_max_ulp:
https://docs.scipy.org/doc/numpy-1.13.0/reference/generated/numpy.testing.assert_array_max_ulp.html

Attached PR implements math.ulp(x).

----------
components: Library (Lib)
messages: 359846
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add math.ulp(x)
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Sun Jan 12 07:38:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jan 2020 12:38:19 +0000
Subject: [issue39310] Add math.ulp(x)
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578832699.71.0.428783530783.issue39310@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17374
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17965

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Sun Jan 12 07:38:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jan 2020 12:38:30 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578832710.89.0.466860790449.issue39310@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Add math.ulp(x) -> Add math.ulp(x): unit in the last place

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Sun Jan 12 07:58:02 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 12 Jan 2020 12:58:02 +0000
Subject: [issue39311] difflib pathlike support for {unified,
 context}_diff() {from, to}file
Message-ID: <1578833882.54.0.425753104323.issue39311@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

>>> tuple(difflib.context_diff(["abc"], ["bcd"], fromfile=Path("example.py")))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/difflib.py", line 1254, in context_diff
    _check_types(a, b, fromfile, tofile, fromfiledate, tofiledate, lineterm)
  File "/usr/local/lib/python3.9/difflib.py", line 1301, in _check_types
    raise TypeError('all arguments must be str, not: %r' % (arg,))
TypeError: all arguments must be str, not: PosixPath('example.py')

IMHO to and from file arguments should accept PathLike objects. If agreed I can prepare a patch.

----------
components: Library (Lib)
messages: 359847
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: difflib pathlike support for {unified,context}_diff() {from,to}file
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39311>
_______________________________________

From report at bugs.python.org  Sun Jan 12 08:33:13 2020
From: report at bugs.python.org (Tal Einat)
Date: Sun, 12 Jan 2020 13:33:13 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1578835993.26.0.0691421413111.issue34732@roundup.psfhosted.org>


Change by Tal Einat <taleinat+python at gmail.com>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Sun Jan 12 08:49:29 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 12 Jan 2020 13:49:29 +0000
Subject: [issue39311] difflib pathlike support for {unified,
 context}_diff() {from, to}file
In-Reply-To: <1578833882.54.0.425753104323.issue39311@roundup.psfhosted.org>
Message-ID: <1578836969.08.0.55697001729.issue39311@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39311>
_______________________________________

From report at bugs.python.org  Sun Jan 12 08:57:11 2020
From: report at bugs.python.org (Tal Einat)
Date: Sun, 12 Jan 2020 13:57:11 +0000
Subject: [issue34732] uuid returns version more than 5
In-Reply-To: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>
Message-ID: <1578837431.85.0.862453737523.issue34732@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

The uuid module is likely used on a huge variety of operating systems and hardware; I feel making UUID.__init__() reject values which it accepted until now would unnecessarily break existing code.  While raising an exception in __init__ seems more natural and correct in theory, it is also a larger break in backwards-compatibility.

I'm specifically worried by the _windll() example in PR GH-9417, in which a non-RFC 4122 conforming UUID is created, leading to the addition of the new "strict" keyword argument so that we can disable the new check in __init__ in this case.  There's a good chance that there are other such scenarios of which we're simply not yet aware.

In light of this, returning None for UUID.version, as in PR GH-9413, actually seems like a very reasonable solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34732>
_______________________________________

From report at bugs.python.org  Sun Jan 12 09:21:06 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 14:21:06 +0000
Subject: [issue14014] codecs.StreamWriter.reset contract not fulfilled
In-Reply-To: <1329242513.77.0.581823861095.issue14014@psf.upfronthosting.co.za>
Message-ID: <1578838866.0.0.435003101702.issue14014@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@lemburg, when you get a chance, please review the PR.  Thanks!

----------
assignee:  -> lemburg
nosy: +cheryl.sabella
versions: +Python 3.8, Python 3.9 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14014>
_______________________________________

From report at bugs.python.org  Sun Jan 12 09:27:40 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 12 Jan 2020 14:27:40 +0000
Subject: [issue39312] Expose placeholder reparse points in Windows
Message-ID: <1578839260.17.0.288692192504.issue39312@roundup.psfhosted.org>


New submission from Eryk Sun <eryksun at gmail.com>:

Windows 10 apparently defaults to disguising placeholder reparse points in python.exe processes, but exposes them to cmd.exe and powershell.exe processes. 

A common example is a user's OneDrive folder, which extensively uses placeholder reparse points for files and directories. The placeholder file attributes include FILE_ATTRIBUTE_REPARSE_POINT, FILE_ATTRIBUTE_OFFLINE, and FILE_ATTRIBUTE_SPARSE_FILE, and the reparse tags are in the set
IO_REPARSE_TAG_CLOUD[_1-F] (0x9000[0-F]01A). Currently, we don't see any of this information in a python.exe process when we call FindFirstFile[Ex]W, GetFileAttributesW, or query file information on a file opened with FILE_FLAG_OPEN_REPARSE_POINT, such as when we call os.lstat. 

The behavior is determined by the process or per-thread placeholder-compatibility mode. The process mode can be queried via RtlQueryProcessPlaceholderCompatibilityMode [1]. The documentation says that "[m]ost Windows applications see exposed placeholders by default". I don't know what criteria Windows is using here, but in my tests with python.exe and a simple command-line test program, the default mode is PHCM_DISGUISE_PLACEHOLDER.

Should Python provide some way to call RtlSetProcessPlaceholderCompatibilityMode [2] to set PHCM_EXPOSE_PLACEHOLDERS mode for the current process? Should os.lstat be modified to temporarily expose placeholders -- for the current thread only -- via RtlSetThreadPlaceholderCompatibilityMode [3]? We can dynamically link to this ntdll function via GetProcAddress. It returns the previous mode, which we can restore after querying the file.

[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtlqueryprocessplaceholdercompatibilitymode
[2] https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtlsetprocessplaceholdercompatibilitymode
[3] https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-rtlsetthreadplaceholdercompatibilitymode

----------
components: Library (Lib), Windows
messages: 359850
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Expose placeholder reparse points in Windows
type: enhancement
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39312>
_______________________________________

From report at bugs.python.org  Sun Jan 12 09:28:39 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 14:28:39 +0000
Subject: [issue39293] Windows 10 64-bit needs reboot
In-Reply-To: <1578690694.46.0.197073018811.issue39293@roundup.psfhosted.org>
Message-ID: <1578839319.99.0.51311220484.issue39293@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39293>
_______________________________________

From report at bugs.python.org  Sun Jan 12 09:30:47 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 14:30:47 +0000
Subject: [issue19557] ast - docs for every node type are missing
In-Reply-To: <1384239144.67.0.857427270426.issue19557@psf.upfronthosting.co.za>
Message-ID: <1578839447.33.0.347607609996.issue19557@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@BTaskaya, thank you.  I'm going to close this issue as a duplicate of that one.

----------
nosy: +cheryl.sabella
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Improve the AST documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19557>
_______________________________________

From report at bugs.python.org  Sun Jan 12 09:35:46 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 14:35:46 +0000
Subject: [issue39295] usage of bitfields in ctypes structures changed between
 3.7.5 and 3.7.6
In-Reply-To: <1578694567.2.0.498689301236.issue39295@roundup.psfhosted.org>
Message-ID: <1578839746.81.0.268884188891.issue39295@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Adding @vinay.sajip to the nosy list as he worked on issue16576.

----------
nosy: +cheryl.sabella, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39295>
_______________________________________

From report at bugs.python.org  Sun Jan 12 09:40:45 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 14:40:45 +0000
Subject: [issue39179] pandas tz_convert() seems to report incorrect date
 conversion
In-Reply-To: <1577888546.9.0.841265032585.issue39179@roundup.psfhosted.org>
Message-ID: <1578840045.81.0.311260188895.issue39179@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39179>
_______________________________________

From report at bugs.python.org  Sun Jan 12 09:47:21 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 12 Jan 2020 14:47:21 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578840441.16.0.526335437703.issue39310@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +mark.dickinson, rhettinger, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Sun Jan 12 10:15:27 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 12 Jan 2020 15:15:27 +0000
Subject: [issue39313] lib2to3 RefactoringTool
 python_grammar_no_print_and_exec_statement
Message-ID: <1578842127.44.0.653457423562.issue39313@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

issue 23896 introduced a grammar without print and exec statements (they both are functions now) but both the lib2to3 cli script and RefactoringTool lacks of that functionality (which is pretty useful for outside users of lib2to3 like formatters)

(RefactoringTool)
        if self.options["print_function"]:
            self.grammar = pygram.python_grammar_no_print_statement
        else:
            self.grammar = pygram.python_grammar


It should be supported here and on the command line script.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 359853
nosy: BTaskaya, benjamin.peterson
priority: normal
severity: normal
status: open
title: lib2to3 RefactoringTool python_grammar_no_print_and_exec_statement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39313>
_______________________________________

From report at bugs.python.org  Sun Jan 12 10:18:27 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 12 Jan 2020 15:18:27 +0000
Subject: [issue39313] lib2to3 RefactoringTool
 python_grammar_no_print_and_exec_statement
In-Reply-To: <1578842127.44.0.653457423562.issue39313@roundup.psfhosted.org>
Message-ID: <1578842307.55.0.855969673529.issue39313@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +17375
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17967

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39313>
_______________________________________

From report at bugs.python.org  Sun Jan 12 11:30:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jan 2020 16:30:18 +0000
Subject: [issue39288] Add math.nextafter(a, b)
In-Reply-To: <1578671482.19.0.587553829591.issue39288@roundup.psfhosted.org>
Message-ID: <1578846618.78.0.213560703097.issue39288@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-39310 to propose to add math.ulp(x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39288>
_______________________________________

From report at bugs.python.org  Sun Jan 12 11:31:37 2020
From: report at bugs.python.org (Aurora)
Date: Sun, 12 Jan 2020 16:31:37 +0000
Subject: [issue39314] Autofill the closing paraenthesis during auto-completion
 for functions which accept no arguments
Message-ID: <1578846697.93.0.381295981609.issue39314@roundup.psfhosted.org>


New submission from Aurora <auroralanes at pm.me>:

If Python is compiled with the GNU readline headers, it will provide autocompletion for Python functions and etc.

In the Python interpreter environment, if a function is typed partially, Python will fill in the rest if a tab character is typed.

If a function accepts no arguments, Python still doesn't fill in the last closing paraenthesis during autocompletion, in the hope that the user will provide arguments, but in such a case it's pointless.

----------
components: Interpreter Core
messages: 359855
nosy: opensource-assist
priority: normal
severity: normal
status: open
title: Autofill the closing paraenthesis during auto-completion for functions which accept no arguments
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39314>
_______________________________________

From report at bugs.python.org  Sun Jan 12 11:46:12 2020
From: report at bugs.python.org (Aurora)
Date: Sun, 12 Jan 2020 16:46:12 +0000
Subject: [issue39304] Don't accept a negative number for the count argument in
 str.replace(old, new[, count])
In-Reply-To: <1578750158.45.0.245853814213.issue39304@roundup.psfhosted.org>
Message-ID: <1578847572.91.0.0387982816996.issue39304@roundup.psfhosted.org>


Aurora <auroralanes at pm.me> added the comment:

@xtreak
Understood, just as an aftermath:
I still disagree a little with such an implementation because it's riding way into terse-coding that it's going against the principles of mathematics, which is the basis of computer science and programming.
Python can use another special keyword or something(e.g. the Ellipsis notation) for this and all similar cases.
You'll get into trouble if you wanna explain such a thing to a mathematician or if you wanna write some pseudo-code based on it, which in both cases they're not gonna look at the underlying implementation.
A bad practice in C, followed by CPython spreaded to others.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39304>
_______________________________________

From report at bugs.python.org  Sun Jan 12 11:51:01 2020
From: report at bugs.python.org (Aurora)
Date: Sun, 12 Jan 2020 16:51:01 +0000
Subject: [issue39314] Autofill the closing paraenthesis during auto-completion
 for functions which accept no arguments at all
In-Reply-To: <1578846697.93.0.381295981609.issue39314@roundup.psfhosted.org>
Message-ID: <1578847861.41.0.826751216779.issue39314@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
title: Autofill the closing paraenthesis during auto-completion for functions which accept no arguments -> Autofill the closing paraenthesis during auto-completion for functions which accept no arguments at all

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39314>
_______________________________________

From report at bugs.python.org  Sun Jan 12 12:31:57 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 12 Jan 2020 17:31:57 +0000
Subject: [issue39290] lib2to3.fixes.fix_import: support imports_as_name in
 traverse_imports
In-Reply-To: <1578676607.69.0.963910000582.issue39290@roundup.psfhosted.org>
Message-ID: <1578850317.43.0.820273297658.issue39290@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
components: +2to3 (2.x to 3.x conversion tool)
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39290>
_______________________________________

From report at bugs.python.org  Sun Jan 12 12:32:07 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 12 Jan 2020 17:32:07 +0000
Subject: [issue39290] lib2to3.fixes.fix_import: support imports_as_name in
 traverse_imports
In-Reply-To: <1578676607.69.0.963910000582.issue39290@roundup.psfhosted.org>
Message-ID: <1578850327.54.0.529914733363.issue39290@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39290>
_______________________________________

From report at bugs.python.org  Sun Jan 12 12:42:04 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 17:42:04 +0000
Subject: [issue38293] Deepcopying property objects results in unexpected
 TypeError
In-Reply-To: <1569601003.51.0.0962889637632.issue38293@roundup.psfhosted.org>
Message-ID: <1578850924.63.0.108550042773.issue38293@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9f3fc6c5b4993f2b362263b494f84793a21aa073 by Miss Islington (bot) (Gu?ni Natan Gunnarsson) in branch 'master':
bpo-38293: Allow shallow and deep copying of property objects (GH-16438)
https://github.com/python/cpython/commit/9f3fc6c5b4993f2b362263b494f84793a21aa073


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38293>
_______________________________________

From report at bugs.python.org  Sun Jan 12 12:42:08 2020
From: report at bugs.python.org (hmathers)
Date: Sun, 12 Jan 2020 17:42:08 +0000
Subject: [issue39315] Lists of objects containing lists
Message-ID: <1578850928.34.0.888723591235.issue39315@roundup.psfhosted.org>


New submission from hmathers <hmathers at gmail.com>:

class Folder():
    papers = []

shelf = []
shelf.append(Folder)
shelf.append(Folder)

shelf[0].papers.append("one")
shelf[1].papers.append("two")
print(shelf[0].papers) #should just print "one" right?

----------
messages: 359858
nosy: hmathers
priority: normal
severity: normal
status: open
title: Lists of objects containing lists
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39315>
_______________________________________

From report at bugs.python.org  Sun Jan 12 12:42:12 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 17:42:12 +0000
Subject: [issue38293] Deepcopying property objects results in unexpected
 TypeError
In-Reply-To: <1569601003.51.0.0962889637632.issue38293@roundup.psfhosted.org>
Message-ID: <1578850932.65.0.267268848193.issue38293@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17376
pull_request: https://github.com/python/cpython/pull/17968

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38293>
_______________________________________

From report at bugs.python.org  Sun Jan 12 12:43:50 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 17:43:50 +0000
Subject: [issue38293] Deepcopying property objects results in unexpected
 TypeError
In-Reply-To: <1569601003.51.0.0962889637632.issue38293@roundup.psfhosted.org>
Message-ID: <1578851030.43.0.0642397348188.issue38293@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38293>
_______________________________________

From report at bugs.python.org  Sun Jan 12 12:45:35 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 17:45:35 +0000
Subject: [issue38293] Deepcopying property objects results in unexpected
 TypeError
In-Reply-To: <1569601003.51.0.0962889637632.issue38293@roundup.psfhosted.org>
Message-ID: <1578851135.97.0.732968905602.issue38293@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17377
pull_request: https://github.com/python/cpython/pull/17969

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38293>
_______________________________________

From report at bugs.python.org  Sun Jan 12 12:45:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 12 Jan 2020 17:45:51 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578851151.35.0.67639689792.issue39310@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also math.isclose() and its PEP 485 which mentions ULP (Unit in the Last Place)... in the "Inappropriate uses" section :-)

* https://docs.python.org/dev/library/math.html#math.isclose
* https://www.python.org/dev/peps/pep-0485/#inappropriate-uses

Extract of an old python-ideas discussion on adding nextafter():

"It's also a little weird to jump from nextafter to isclose, since AFAIK
they have pretty much non-overlapping use cases..."

https://mail.python.org/pipermail/python-ideas/2017-February/044832.html

Other links:

* https://en.wikipedia.org/wiki/Unit_in_the_last_place
* https://en.wikipedia.org/wiki/Machine_epsilon
* https://en.wikipedia.org/wiki/IEEE_754

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Sun Jan 12 13:00:30 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 18:00:30 +0000
Subject: [issue38293] Deepcopying property objects results in unexpected
 TypeError
In-Reply-To: <1569601003.51.0.0962889637632.issue38293@roundup.psfhosted.org>
Message-ID: <1578852030.55.0.422345802368.issue38293@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4be97260351f214d3c8b8477682323bb52ee2af3 by Miss Islington (bot) in branch '3.7':
bpo-38293: Allow shallow and deep copying of property objects (GH-16438)
https://github.com/python/cpython/commit/4be97260351f214d3c8b8477682323bb52ee2af3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38293>
_______________________________________

From report at bugs.python.org  Sun Jan 12 13:04:21 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 18:04:21 +0000
Subject: [issue38293] Deepcopying property objects results in unexpected
 TypeError
In-Reply-To: <1569601003.51.0.0962889637632.issue38293@roundup.psfhosted.org>
Message-ID: <1578852261.92.0.33874118488.issue38293@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3043ec7d6aed402218404c25179e734166c7fbe0 by Miss Islington (bot) in branch '3.8':
bpo-38293: Allow shallow and deep copying of property objects (GH-16438)
https://github.com/python/cpython/commit/3043ec7d6aed402218404c25179e734166c7fbe0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38293>
_______________________________________

From report at bugs.python.org  Sun Jan 12 13:18:54 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 12 Jan 2020 18:18:54 +0000
Subject: [issue39315] Lists of objects containing lists
In-Reply-To: <1578850928.34.0.888723591235.issue39315@roundup.psfhosted.org>
Message-ID: <1578853134.45.0.81485650783.issue39315@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

You are appending to the class attribute where both shelf[0] and shelf[1] refers to the same list as seen by output of id. You might want to create an instance variable and use it for mutating across different instances. This could help : https://docs.python.org/3/tutorial/classes.html#class-and-instance-variables


class Folder():
    papers = []

    def __init__(self):
        self.papers_self = []

shelf = []
shelf.append(Folder)
shelf.append(Folder)

print(f"{id(shelf[0]) = }")
print(f"{id(shelf[1]) = }")

shelf = []
shelf.append(Folder())
shelf.append(Folder())

print(f"{id(shelf[0].papers_self) = }")
print(f"{id(shelf[1].papers_self) = }")

shelf[0].papers_self.append("one")
shelf[1].papers_self.append("two")
print(f"{shelf[0].papers_self = }")
print(f"{shelf[1].papers_self = }")


id(shelf[0]) = 140411765635376
id(shelf[1]) = 140411765635376
id(shelf[0].papers_self) = 140411720636864
id(shelf[1].papers_self) = 140411720668608
shelf[0].papers_self = ['one']
shelf[1].papers_self = ['two']

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39315>
_______________________________________

From report at bugs.python.org  Sun Jan 12 13:29:10 2020
From: report at bugs.python.org (hmathers)
Date: Sun, 12 Jan 2020 18:29:10 +0000
Subject: [issue39315] Lists of objects containing lists
In-Reply-To: <1578850928.34.0.888723591235.issue39315@roundup.psfhosted.org>
Message-ID: <1578853750.04.0.741569265327.issue39315@roundup.psfhosted.org>


hmathers <hmathers at gmail.com> added the comment:

I should have known I was just doing something wrong. Thank you for your help!

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39315>
_______________________________________

From report at bugs.python.org  Sun Jan 12 13:38:37 2020
From: report at bugs.python.org (kornicameister)
Date: Sun, 12 Jan 2020 18:38:37 +0000
Subject: [issue39308] Literal[True] prints as Literal[1] in some cases
In-Reply-To: <1578785715.62.0.203170094807.issue39308@roundup.psfhosted.org>
Message-ID: <1578854317.52.0.155750816374.issue39308@roundup.psfhosted.org>


kornicameister <kornicameister at gmail.com> added the comment:

I will play around and maybe submit PR later this evening.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39308>
_______________________________________

From report at bugs.python.org  Sun Jan 12 14:22:27 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 12 Jan 2020 19:22:27 +0000
Subject: [issue39315] Lists of objects containing lists
In-Reply-To: <1578850928.34.0.888723591235.issue39315@roundup.psfhosted.org>
Message-ID: <1578856947.14.0.617348060394.issue39315@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

No problem, you're welcome :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39315>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:04:49 2020
From: report at bugs.python.org (Giacomo Mazzamuto)
Date: Sun, 12 Jan 2020 20:04:49 +0000
Subject: [issue39276] type() cause segmentation fault in callback function
 called from C extension
In-Reply-To: <1578577934.03.0.00618526975979.issue39276@roundup.psfhosted.org>
Message-ID: <1578859489.08.0.320928300954.issue39276@roundup.psfhosted.org>


Giacomo Mazzamuto <g.mazzamuto at gmail.com> added the comment:

Hello,

the segmentation fault is also resolved by finalizing the initialization of InternalType by calling PyType_Ready(&InternalType), just like you do with ExternalType

----------
nosy: +Giacomo Mazzamuto

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39276>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:27:25 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 20:27:25 +0000
Subject: [issue38330] httplib specifies content-length when transfer-encoding
 present
In-Reply-To: <1569875041.02.0.374553203578.issue38330@roundup.psfhosted.org>
Message-ID: <1578860845.03.0.304915396378.issue38330@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Hi @apmatthews, thank you for the report and for the pull request.  Unfortunately, Python 2.7 reached end of life on 1/1/2020, so no additional changes are being incorporated into Python 2.  Looking at the documentation for Python 3, I think it's OK there (https://docs.python.org/3/library/http.client.html#http.client.HTTPConnection.request).

----------
nosy: +cheryl.sabella
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38330>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:29:13 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Jan 2020 20:29:13 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1578860953.34.0.479152165603.issue16575@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests: +17378
pull_request: https://github.com/python/cpython/pull/17970

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:29:49 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 12 Jan 2020 20:29:49 +0000
Subject: [issue38356] test_asyncio: SubprocessThreadedWatcherTests leaks
 threads
In-Reply-To: <1570056781.39.0.894014377654.issue38356@roundup.psfhosted.org>
Message-ID: <1578860989.31.0.0815109734267.issue38356@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I hope it is fixed now.
> Thanks, Kyle!

No problem, thanks for looking over it. 

Let me know if the warning comes up again. If it does, I'll be sure to look into it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38356>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:31:37 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Jan 2020 20:31:37 +0000
Subject: [issue4347] Circular dependency causes SystemError when adding new
 syntax
In-Reply-To: <1227022091.75.0.852526924329.issue4347@psf.upfronthosting.co.za>
Message-ID: <1578861097.75.0.41484628705.issue4347@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think there is nothing missing now that the C version of pgen is gone. And parsetok is already rebuilt when gramminit.h changes:

Python/compile.o Python/symtable.o Python/ast_unparse.o Python/ast.o Python/future.o Parser/parsetok.o: $(srcdir)/Include/graminit.h           ? $(srcdir)/Include/Python-ast.h

Feel free to re-open if we are missing something :)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4347>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:32:22 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 12 Jan 2020 20:32:22 +0000
Subject: [issue39177] In tkinter, simple dialogs, askstrings,
 etc. with flexible coordinates and no viewable parent.
In-Reply-To: <1577863304.66.0.670645943584.issue39177@roundup.psfhosted.org>
Message-ID: <1578861142.51.0.331398476475.issue39177@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39177>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:35:39 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Jan 2020 20:35:39 +0000
Subject: [issue1531415] parsetok.c emits warnings by writing to stderr
Message-ID: <1578861339.09.0.424195816884.issue1531415@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The C version of pgen is gone so the circular dependency should not be a problem as as far as I can tell, Parser/parsetok.c does not emit warnings anymore (the functions are unused). Maybe we should just clean that code instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1531415>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:37:35 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Jan 2020 20:37:35 +0000
Subject: [issue1531415] parsetok.c emits warnings by writing to stderr
Message-ID: <1578861455.59.0.379603222647.issue1531415@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

https://github.com/python/cpython/pull/17971

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1531415>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:38:56 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Jan 2020 20:38:56 +0000
Subject: [issue3530] ast.NodeTransformer doc bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1578861536.58.0.520450933559.issue3530@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 6680f4a9f5d15ab82b2ab6266c6f917cb78c919a by Pablo Galindo (Batuhan Ta?kaya) in branch 'master':
bpo-3530: Add advice on when to correctly use fix_missing_locations in the AST docs (GH-17172)
https://github.com/python/cpython/commit/6680f4a9f5d15ab82b2ab6266c6f917cb78c919a


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:39:04 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 20:39:04 +0000
Subject: [issue3530] ast.NodeTransformer doc bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1578861544.89.0.231455352679.issue3530@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17379
pull_request: https://github.com/python/cpython/pull/17972

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:39:11 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 20:39:11 +0000
Subject: [issue3530] ast.NodeTransformer doc bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1578861551.08.0.238759253358.issue3530@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17380
pull_request: https://github.com/python/cpython/pull/17973

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:40:00 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Jan 2020 20:40:00 +0000
Subject: [issue3530] ast.NodeTransformer doc bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1578861600.33.0.246705779706.issue3530@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:41:37 2020
From: report at bugs.python.org (Batuhan)
Date: Sun, 12 Jan 2020 20:41:37 +0000
Subject: [issue39313] lib2to3 provide a way to use exec as a function in
 RefactoringTool
In-Reply-To: <1578842127.44.0.653457423562.issue39313@roundup.psfhosted.org>
Message-ID: <1578861697.66.0.920775117667.issue39313@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

After discussing with @pablogsal, instead of offering 2 options that one overlaps another we added -e option to 2to3.main and exec_function option (alongside print_funtion) to RefactoringTool.

----------
nosy: +pablogsal
title: lib2to3 RefactoringTool python_grammar_no_print_and_exec_statement -> lib2to3 provide a way to use exec as a function in RefactoringTool

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39313>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:44:37 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 20:44:37 +0000
Subject: [issue3530] ast.NodeTransformer doc bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1578861877.22.0.793142720413.issue3530@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ef0af30e507a29dae03aae40459b9c44c96f260d by Miss Islington (bot) in branch '3.8':
bpo-3530: Add advice on when to correctly use fix_missing_locations in the AST docs (GH-17172)
https://github.com/python/cpython/commit/ef0af30e507a29dae03aae40459b9c44c96f260d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:44:29 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 20:44:29 +0000
Subject: [issue3530] ast.NodeTransformer doc bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1578861869.03.0.654184704007.issue3530@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e222b4c69f99953a14ded52497a9909e34fc3893 by Miss Islington (bot) in branch '3.7':
bpo-3530: Add advice on when to correctly use fix_missing_locations in the AST docs (GH-17172)
https://github.com/python/cpython/commit/e222b4c69f99953a14ded52497a9909e34fc3893


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3530>
_______________________________________

From report at bugs.python.org  Sun Jan 12 15:55:57 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Jan 2020 20:55:57 +0000
Subject: [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1578862557.47.0.776627127014.issue16575@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 9dbf5d3bc2033940cdca35440cf08814544f81e4 by Vinay Sajip in branch '3.7':
[3.7] bpo-16575: Disabled checks for union types being passed by value. (GH-17960) (GH-17970)
https://github.com/python/cpython/commit/9dbf5d3bc2033940cdca35440cf08814544f81e4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16575>
_______________________________________

From report at bugs.python.org  Sun Jan 12 16:08:39 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 12 Jan 2020 21:08:39 +0000
Subject: [issue39295] usage of bitfields in ctypes structures changed between
 3.7.5 and 3.7.6
In-Reply-To: <1578694567.2.0.498689301236.issue39295@roundup.psfhosted.org>
Message-ID: <1578863319.89.0.55286477279.issue39295@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The change which caused this breakage has been reverted, at least for now. bpo-16576 is related to bpo-16575 (which is about unions rather than bitfields, but the cases have things in common).

Refer to bpo-16575 for PRs relating to the reversion. This includes 3.7. You are welcome to try the latest version (will need building from source, or waiting for the next release).

There is still an underlying ctypes/libffi issue, and the check was only supposed to catch instances being passed by value, rather than pointers to such structures/unions being passed. It may be that the check is faulty - your example will be used to investigate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39295>
_______________________________________

From report at bugs.python.org  Sun Jan 12 16:13:44 2020
From: report at bugs.python.org (Alex Hall)
Date: Sun, 12 Jan 2020 21:13:44 +0000
Subject: [issue39316] settrace skips lines when chaining methods without
 arguments
Message-ID: <1578863624.84.0.650995733403.issue39316@roundup.psfhosted.org>


New submission from Alex Hall <alex.mojaki at gmail.com>:

When stepping through a multiline expression like this:

```
print(slug
      .replace("_", " ")
      .title()
      .upper()
      .replace("a", "b")
      .lower()
      .replace("The ", "the "))
```

only these lines are hit by the tracer function:

15 print(slug
16       .replace("_", " ")
19       .replace("a", "b")
21       .replace("The ", "the "))

I'm guessing the problem is that there are no expressions on the other lines, as the attributes and calls all start with slug.

----------
components: Interpreter Core
files: trace_skipping_lines_bug.py
messages: 359878
nosy: alexmojaki
priority: normal
severity: normal
status: open
title: settrace skips lines when chaining methods without arguments
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48837/trace_skipping_lines_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39316>
_______________________________________

From report at bugs.python.org  Sun Jan 12 16:42:05 2020
From: report at bugs.python.org (kornicameister)
Date: Sun, 12 Jan 2020 21:42:05 +0000
Subject: [issue39308] Literal[True] prints as Literal[1] in some cases
In-Reply-To: <1578785715.62.0.203170094807.issue39308@roundup.psfhosted.org>
Message-ID: <1578865325.06.0.479408305647.issue39308@roundup.psfhosted.org>


Change by kornicameister <kornicameister at gmail.com>:


----------
keywords: +patch
pull_requests: +17381
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17974

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39308>
_______________________________________

From report at bugs.python.org  Sun Jan 12 17:13:35 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 12 Jan 2020 22:13:35 +0000
Subject: [issue39313] lib2to3 provide a way to use exec as a function in
 RefactoringTool
In-Reply-To: <1578842127.44.0.653457423562.issue39313@roundup.psfhosted.org>
Message-ID: <1578867215.09.0.255615051984.issue39313@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 61b14151cc92021a10f94765eaa152ed04eb262a by Miss Islington (bot) (Batuhan Ta?kaya) in branch 'master':
bpo-39313: Add an option to RefactoringTool for using exec as a function (GH-17967)
https://github.com/python/cpython/commit/61b14151cc92021a10f94765eaa152ed04eb262a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39313>
_______________________________________

From report at bugs.python.org  Sun Jan 12 17:24:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 12 Jan 2020 22:24:33 +0000
Subject: [issue39313] lib2to3 provide a way to use exec as a function in
 RefactoringTool
In-Reply-To: <1578842127.44.0.653457423562.issue39313@roundup.psfhosted.org>
Message-ID: <1578867873.41.0.769031329594.issue39313@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39313>
_______________________________________

From report at bugs.python.org  Sun Jan 12 17:31:55 2020
From: report at bugs.python.org (Abhilash Raj)
Date: Sun, 12 Jan 2020 22:31:55 +0000
Subject: [issue32021] Brotli encoding is not recognized by mimetypes
In-Reply-To: <1510645430.68.0.213398074469.issue32021@psf.upfronthosting.co.za>
Message-ID: <1578868315.42.0.604026846445.issue32021@roundup.psfhosted.org>


Abhilash Raj <raj.abhilash1 at gmail.com> added the comment:


New changeset b2b4a51f7463a0392456f7772f33223e57fa4ccc by Abhilash Raj (Philip McMahon) in branch 'master':
bpo-32021: Support brotli .br encoding in mimetypes (#12200)
https://github.com/python/cpython/commit/b2b4a51f7463a0392456f7772f33223e57fa4ccc


----------
nosy: +maxking

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32021>
_______________________________________

From report at bugs.python.org  Sun Jan 12 17:33:29 2020
From: report at bugs.python.org (Abhilash Raj)
Date: Sun, 12 Jan 2020 22:33:29 +0000
Subject: [issue32021] Brotli encoding is not recognized by mimetypes
In-Reply-To: <1510645430.68.0.213398074469.issue32021@psf.upfronthosting.co.za>
Message-ID: <1578868409.3.0.749064762871.issue32021@roundup.psfhosted.org>


Change by Abhilash Raj <raj.abhilash1 at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32021>
_______________________________________

From report at bugs.python.org  Sun Jan 12 18:34:32 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 12 Jan 2020 23:34:32 +0000
Subject: [issue16379] SQLite error code not exposed to python
In-Reply-To: <1351764878.68.0.13361347428.issue16379@psf.upfronthosting.co.za>
Message-ID: <1578872072.55.0.875440034697.issue16379@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

What would it take to get this merged?

----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16379>
_______________________________________

From report at bugs.python.org  Sun Jan 12 18:35:04 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 12 Jan 2020 23:35:04 +0000
Subject: [issue16379] SQLite error code not exposed to python
In-Reply-To: <1351764878.68.0.13361347428.issue16379@psf.upfronthosting.co.za>
Message-ID: <1578872104.17.0.483410122959.issue16379@roundup.psfhosted.org>


Change by Ned Batchelder <ned at nedbatchelder.com>:


_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16379>
_______________________________________

From report at bugs.python.org  Sun Jan 12 21:01:35 2020
From: report at bugs.python.org (Tim Peters)
Date: Mon, 13 Jan 2020 02:01:35 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578880895.54.0.454718639487.issue39310@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

+1

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Sun Jan 12 21:29:16 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 13 Jan 2020 02:29:16 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578882556.47.0.0529186670331.issue39310@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Thank you Victor!

Any chance you could look at fma too? #29282

(The reward for a job well done is to be given more jobs :-)

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Sun Jan 12 21:30:39 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 13 Jan 2020 02:30:39 +0000
Subject: [issue29282] Fused multiply-add: proposal to add math.fma()
In-Reply-To: <1484560897.19.0.0955404368118.issue29282@psf.upfronthosting.co.za>
Message-ID: <1578882639.32.0.85160647725.issue29282@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29282>
_______________________________________

From report at bugs.python.org  Sun Jan 12 21:47:44 2020
From: report at bugs.python.org (Matthew Newville)
Date: Mon, 13 Jan 2020 02:47:44 +0000
Subject: [issue39295] usage of bitfields in ctypes structures changed between
 3.7.5 and 3.7.6
In-Reply-To: <1578694567.2.0.498689301236.issue39295@roundup.psfhosted.org>
Message-ID: <1578883664.74.0.88101039327.issue39295@roundup.psfhosted.org>


Matthew Newville <matt.newville at gmail.com> added the comment:

Thanks for the reply and the fix -- I have not tried the master branch, but will try to do that soon. If I understand correctly, we will have to stick with our kludgy "workaround" version in order to work with Python 3.7.6 and 3.8.1.  Or is there a better approach than our workaround of using

class access_rights_handler_args(ctypes.Structure):
    "access rights arguments"
    _fields_ = [('chid', ctypes.c_long),
                ('access', ctypes.c_ubyte)]

?   

As a long-time (20 years) Python user and first-time reporter of a bug to main Python, I'm both very appreciative of the effort and slightly alarmed by reading the messages related to #16575.  From far outside the Python dev world, it appears that an old, poorly verified bug report inspired a change that was actually not well tested and so incorrectly broke valid code without deprecation. Trying to be as polite as possible, this appears to indicate a poor testing process, if not a poor understanding of the actual code in question. 

Trust is an important aspect of open source software, and much easier to lose than gain.  I strongly encourage you and other Python devs to carefully assess what went wrong here and to work out (and write down) what will be done going forward to avoid such problems. Simply rolling this change back and saying "sorry, but we're overworked volunteers and stuff happens" is not going to regain lost trust. In fact, it's pretty close to a promise that this sort of issue will happen again. I think that you may want to make sure that it is not the take-away message here.
Sorry if that sounds in any way unappreciative.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39295>
_______________________________________

From report at bugs.python.org  Sun Jan 12 22:28:04 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Jan 2020 03:28:04 +0000
Subject: [issue39307] Memory leak in parsetok
In-Reply-To: <1578773613.93.0.403344641263.issue39307@roundup.psfhosted.org>
Message-ID: <1578886084.2.0.949437968204.issue39307@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39307>
_______________________________________

From report at bugs.python.org  Sun Jan 12 22:43:34 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 13 Jan 2020 03:43:34 +0000
Subject: [issue39311] difflib pathlike support for {unified,
 context}_diff() {from, to}file
In-Reply-To: <1578833882.54.0.425753104323.issue39311@roundup.psfhosted.org>
Message-ID: <1578887014.72.0.624993561628.issue39311@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Elsewhere users of Path objects must explicitly coerce to str.  For example:  json.dumps(str(Path("example.py"))).   This makes good sense to me.  We don't want to add an dependency on pathlib just to recognize Path objects.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39311>
_______________________________________

From report at bugs.python.org  Sun Jan 12 22:53:01 2020
From: report at bugs.python.org (dai dai)
Date: Mon, 13 Jan 2020 03:53:01 +0000
Subject: [issue39317] This new feature or bug about operator "- -"?
Message-ID: <1578887581.87.0.228721168056.issue39317@roundup.psfhosted.org>


New submission from dai dai <daidai4269 at gmail.com>:

```py
print(3 - - 2)
print(3 + + 2)
"""output
5
5
"""
```

----------
components: Windows
messages: 359886
nosy: dai dai, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: This new feature or bug about operator "- -"?
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39317>
_______________________________________

From report at bugs.python.org  Sun Jan 12 23:45:20 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 13 Jan 2020 04:45:20 +0000
Subject: [issue39317] This new feature or bug about operator "- -"?
In-Reply-To: <1578887581.87.0.228721168056.issue39317@roundup.psfhosted.org>
Message-ID: <1578890720.46.0.606609530262.issue39317@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The interpreter parses those as:
 3 - (-2)
 3 + (+2)

The first is a binary operator and the second is a unary operator..

----------
nosy: +rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39317>
_______________________________________

From report at bugs.python.org  Sun Jan 12 23:56:47 2020
From: report at bugs.python.org (Robert Xiao)
Date: Mon, 13 Jan 2020 04:56:47 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
Message-ID: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>


New submission from Robert Xiao <nneonneo at gmail.com>:

tempfile.NamedTemporaryFile creates its wrapper like so:

    try:
        file = _io.open(fd, mode, buffering=buffering,
                        newline=newline, encoding=encoding, errors=errors)

        return _TemporaryFileWrapper(file, name, delete)
    except BaseException:
        _os.unlink(name)
        _os.close(fd)
        raise

If _TemporaryFileWrapper throws any kind of exception (even KeyboardInterrupt), this closes `fd` but leaks a valid `file` pointing to that fd. The `file` will later attempt to close the `fd` when it is collected, which can lead to subtle bugs. (This particular issue contributed to this bug: https://nedbatchelder.com/blog/202001/bug_915_please_help.html)

This should probably be rewritten as:

    try:
        file = _io.open(fd, mode, buffering=buffering,
                        newline=newline, encoding=encoding, errors=errors)
    except:
        _os.unlink(name)
        _os.close(fd)
        raise

    try:
        return _TemporaryFileWrapper(file, name, delete)
    except BaseException:
        _os.unlink(name)
        file.close()
        raise

or perhaps use nested try blocks to avoid the _os.unlink duplication.

----------
components: Library (Lib)
messages: 359888
nosy: nneonneo
priority: normal
severity: normal
status: open
title: NamedTemporaryFile could cause double-close on an fd if _TemporaryFileWrapper throws
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/issue39318>
_______________________________________

From report at bugs.python.org  Mon Jan 13 00:53:55 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 13 Jan 2020 05:53:55 +0000
Subject: [issue39295] usage of bitfields in ctypes structures changed between
 3.7.5 and 3.7.6
In-Reply-To: <1578694567.2.0.498689301236.issue39295@roundup.psfhosted.org>
Message-ID: <1578894835.51.0.460484809271.issue39295@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> it appears that an old, poorly verified bug report 

Why do you say the bug report is poorly verified? The libffi maintainers accept it is an issue.

https://github.com/libffi/libffi/issues/33

> inspired a change that was actually not well tested and so incorrectly broke valid code without deprecation. Trying to be as polite as possible, this appears to indicate a poor testing process, if not a poor understanding of the actual code in question.

Well, the original developer of ctypes is no longer involved in maintaining it. Those of us who try to address ctypes issues are perhaps not as well-versed in the code as the original developer and maintainer, but we do our best. This of course applies to other areas in CPython, and many other projects besides.

The change was accompanied by tests, which have been no doubt found wanting, but do *you* write software which guarantees no bugs ever in released versions? Using your example above, I will look into what was missed and try to improve the checking. The underlying libffi issue is a real one. The change wasn't introduced in a cavalier manner, as you seem to be suggesting.

> I strongly encourage you and other Python devs to carefully assess what went wrong here and to work out (and write down) what will be done going forward to avoid such problems. Simply rolling this change back and saying "sorry, but we're overworked volunteers and stuff happens" is not going to regain lost trust. In fact, it's pretty close to a promise that this sort of issue will happen again. I think that you may want to make sure that it is not the take-away message here.
Sorry if that sounds in any way unappreciative.  Thanks.

Well, "stuff happens" is true, and I don't mean to trivialise anything. But almost all released non-trivial software has bugs. If we didn't have a good process, then we could perhaps be held to task, but that's not the case. That things sometimes slip through the cracks is pretty much a given in software development - not confined to CPython.

My backporting the changes to 3.8 and 3.7 were premature, and I have learned that lesson. It's often a matter of judgement, and sometimes that can go wrong.

Do you regularly test your code with Python alpha and beta versions? I ask because I may reinstate the check for Python 3.9 after seeing what false-positive cases were missed here. Python 3.9 is at alpha 2 level right now. Continued feedback could help to minimise the chances of future surprises.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39295>
_______________________________________

From report at bugs.python.org  Mon Jan 13 01:54:51 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 13 Jan 2020 06:54:51 +0000
Subject: [issue28166] WindowsConsoleIO misbehavior when Ctrl+C is ignored
In-Reply-To: <1473927025.25.0.183534906845.issue28166@psf.upfronthosting.co.za>
Message-ID: <1578898491.03.0.665388034487.issue28166@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +17383
pull_request: https://github.com/python/cpython/pull/17976

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28166>
_______________________________________

From report at bugs.python.org  Mon Jan 13 02:02:14 2020
From: report at bugs.python.org (Chris Withers)
Date: Mon, 13 Jan 2020 07:02:14 +0000
Subject: [issue39222] unittest.mock.Mock.parent is broken or undocumented
In-Reply-To: <1578236312.03.0.58171840403.issue39222@roundup.psfhosted.org>
Message-ID: <1578898934.33.0.80951451915.issue39222@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

Ah right. Well, it's called `parent` in the __init__ as that's what the attribute used to be called. 

My suggestion would be to add `parent` to the docs @xtreak links to as a way to resolve this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39222>
_______________________________________

From report at bugs.python.org  Mon Jan 13 02:05:36 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 13 Jan 2020 07:05:36 +0000
Subject: [issue28166] WindowsConsoleIO misbehavior when Ctrl+C is ignored
In-Reply-To: <1473927025.25.0.183534906845.issue28166@psf.upfronthosting.co.za>
Message-ID: <1578899136.1.0.952764382621.issue28166@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
versions: +Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28166>
_______________________________________

From report at bugs.python.org  Mon Jan 13 02:53:39 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Jan 2020 07:53:39 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578902019.63.0.31317094872.issue39310@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Steven]

> Any chance you could look at fma too? #29282

fma is hard, for reasons explained in the issue you linked to. If you have suggestions for resolving the difficulties, please do add them to that issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Mon Jan 13 03:10:01 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Jan 2020 08:10:01 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578903001.92.0.724477400512.issue39318@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +serhiy.storchaka
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Mon Jan 13 03:31:10 2020
From: report at bugs.python.org (Seth Troisi)
Date: Mon, 13 Jan 2020 08:31:10 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578904270.69.0.411048540247.issue39318@roundup.psfhosted.org>


Change by Seth Troisi <braintwo at gmail.com>:


----------
nosy: +Seth.Troisi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Mon Jan 13 03:36:56 2020
From: report at bugs.python.org (Wouter De Borger)
Date: Mon, 13 Jan 2020 08:36:56 +0000
Subject: [issue39168] Generic type subscription is a huge toll on Python
 performance
In-Reply-To: <1577726230.5.0.713641828615.issue39168@roundup.psfhosted.org>
Message-ID: <1578904616.81.0.775431717002.issue39168@roundup.psfhosted.org>


Change by Wouter De Borger <w.deborger at gmail.com>:


----------
nosy: +Wouter De Borger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39168>
_______________________________________

From report at bugs.python.org  Mon Jan 13 04:19:41 2020
From: report at bugs.python.org (Albert Zeyer)
Date: Mon, 13 Jan 2020 09:19:41 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578907181.7.0.852951773541.issue39318@roundup.psfhosted.org>


Albert Zeyer <albzey at googlemail.com> added the comment:

Instead of `except:` and `except BaseException:`, I think better use `except Exception:`.

For further discussion and reference, also see the discussion here: https://news.ycombinator.com/item?id=22028581

----------
nosy: +Albert.Zeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:00:37 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 13 Jan 2020 10:00:37 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1578909637.61.0.154081367988.issue26317@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Any progress?

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:03:07 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 13 Jan 2020 10:03:07 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1578909787.38.0.841843173858.issue26317@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I met this issue during I compile with gcc9 on my local mac machine.
This issue should be fixed..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:08:40 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 13 Jan 2020 10:08:40 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1578910120.97.0.35356573779.issue26317@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:15:38 2020
From: report at bugs.python.org (Fabio Sangiovanni)
Date: Mon, 13 Jan 2020 10:15:38 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578910538.81.0.0956217432746.issue39318@roundup.psfhosted.org>


Change by Fabio Sangiovanni <sjh+bugspython at sanjioh.org>:


----------
nosy: +sanjioh

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:25:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Jan 2020 10:25:36 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578911136.2.0.439835563956.issue39318@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:35:51 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Jan 2020 10:35:51 +0000
Subject: [issue39307] Memory leak in parsetok
In-Reply-To: <1578773613.93.0.403344641263.issue39307@roundup.psfhosted.org>
Message-ID: <1578911751.31.0.0742015751069.issue39307@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 7ba6f18de2582755ae31888ba6a4237d96dddc48 by Pablo Galindo (Alex Henrie) in branch 'master':
bpo-39307: Fix memory leak on error path in parsetok (GH-17953)
https://github.com/python/cpython/commit/7ba6f18de2582755ae31888ba6a4237d96dddc48


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39307>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:36:10 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jan 2020 10:36:10 +0000
Subject: [issue39307] Memory leak in parsetok
In-Reply-To: <1578773613.93.0.403344641263.issue39307@roundup.psfhosted.org>
Message-ID: <1578911770.17.0.49772976189.issue39307@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17384
pull_request: https://github.com/python/cpython/pull/17978

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39307>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:36:16 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jan 2020 10:36:16 +0000
Subject: [issue39307] Memory leak in parsetok
In-Reply-To: <1578773613.93.0.403344641263.issue39307@roundup.psfhosted.org>
Message-ID: <1578911776.02.0.0400038722484.issue39307@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17385
pull_request: https://github.com/python/cpython/pull/17979

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39307>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:36:46 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Jan 2020 10:36:46 +0000
Subject: [issue39307] Memory leak in parsetok
In-Reply-To: <1578773613.93.0.403344641263.issue39307@roundup.psfhosted.org>
Message-ID: <1578911806.22.0.265649888042.issue39307@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39307>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:38:15 2020
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Jan 2020 10:38:15 +0000
Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support
In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org>
Message-ID: <1578911895.06.0.417895307938.issue36020@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +17386
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17980

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36020>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:54:27 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jan 2020 10:54:27 +0000
Subject: [issue39307] Memory leak in parsetok
In-Reply-To: <1578773613.93.0.403344641263.issue39307@roundup.psfhosted.org>
Message-ID: <1578912867.79.0.295123662107.issue39307@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9671b6b3b3e480fbc4b14aab7008b90b38767f55 by Miss Islington (bot) in branch '3.8':
bpo-39307: Fix memory leak on error path in parsetok (GH-17953)
https://github.com/python/cpython/commit/9671b6b3b3e480fbc4b14aab7008b90b38767f55


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39307>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:58:01 2020
From: report at bugs.python.org (Aurora)
Date: Mon, 13 Jan 2020 10:58:01 +0000
Subject: [issue39319] ntpath module must not be available on POSIX platforms
Message-ID: <1578913081.93.0.570366653364.issue39319@roundup.psfhosted.org>


New submission from Aurora <auroralanes at pm.me>:

According to https://docs.python.org/dev/library/undoc.html the 'ntpath' module is an "Implementation of os.path on Win32 and Win64 platforms".
Just like all other Windows-specific modules(like winreg),'ntpath' must not be available for use on a POSIX system like Linux.
I guess that 'posixpath' is also available on Windows, that if it is, it must not be available too.

----------
components: Interpreter Core
messages: 359897
nosy: opensource-assist
priority: normal
severity: normal
status: open
title: ntpath module must not be available on POSIX platforms
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39319>
_______________________________________

From report at bugs.python.org  Mon Jan 13 05:58:15 2020
From: report at bugs.python.org (Aurora)
Date: Mon, 13 Jan 2020 10:58:15 +0000
Subject: [issue39319] ntpath module must not be available on POSIX platforms
In-Reply-To: <1578913081.93.0.570366653364.issue39319@roundup.psfhosted.org>
Message-ID: <1578913095.59.0.516578371024.issue39319@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
components: +Library (Lib) -Interpreter Core
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39319>
_______________________________________

From report at bugs.python.org  Mon Jan 13 06:40:11 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 13 Jan 2020 11:40:11 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578915611.94.0.269762644141.issue39318@roundup.psfhosted.org>


Change by Ned Batchelder <ned at nedbatchelder.com>:


----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Mon Jan 13 06:44:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 11:44:49 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578915889.33.0.648552682571.issue39310@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0b2ab21956fbab8eab6d064060d4544499730316 by Victor Stinner in branch 'master':
bpo-39310: Add math.ulp(x) (GH-17965)
https://github.com/python/cpython/commit/0b2ab21956fbab8eab6d064060d4544499730316


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Mon Jan 13 06:47:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 11:47:40 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578916060.34.0.711742454298.issue39310@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Mon Jan 13 06:48:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 11:48:47 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578916127.59.0.596806476303.issue39310@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17387
pull_request: https://github.com/python/cpython/pull/17982

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Mon Jan 13 06:59:17 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Jan 2020 11:59:17 +0000
Subject: [issue38903] #if 0 block on parsetok.c
In-Reply-To: <1574556805.21.0.874814643739.issue38903@roundup.psfhosted.org>
Message-ID: <1578916757.37.0.0374353637563.issue38903@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38903>
_______________________________________

From report at bugs.python.org  Mon Jan 13 06:59:52 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Jan 2020 11:59:52 +0000
Subject: [issue1531415] parsetok.c emits warnings by writing to stderr
Message-ID: <1578916792.71.0.157417436002.issue1531415@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Closed by https://github.com/python/cpython/pull/17365

----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1531415>
_______________________________________

From report at bugs.python.org  Mon Jan 13 07:18:10 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 13 Jan 2020 12:18:10 +0000
Subject: [issue39319] ntpath module must not be available on POSIX platforms
In-Reply-To: <1578913081.93.0.570366653364.issue39319@roundup.psfhosted.org>
Message-ID: <1578917890.03.0.0438921915066.issue39319@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

No, ntpath and posixpath are cross-platform. They are tested on all platforms, and the os.path documentation lists them and notes that "you can also import and use the individual modules if you want to manipulate a path that is always in one of the different formats".

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39319>
_______________________________________

From report at bugs.python.org  Mon Jan 13 07:28:10 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 13 Jan 2020 12:28:10 +0000
Subject: [issue39320] Handle unpacking of */** arguments and rvalues in the
 compiler
Message-ID: <1578918490.54.0.342025462897.issue39320@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

Currently the unpacking of starred values in arguments and the right hand side of assignments is handled in the interpreter without any help from the compiler.
The layout of arguments and values is visible to the compiler, so the compiler should do more of the work.

We can replace the complex bytecodes used in unpacking with simpler more focused ones.
Specifically the collection building operations 
BUILD_LIST_UNPACK, BUILD_TUPLE_UNPACK, BUILD_SET_UNPACK and BUILD_TUPLE_UNPACK_WITH_CALL
can be replaced with simpler, and self-explanatory operations:
LIST_TO_TUPLE, LIST_EXTEND, SET_UPDATE

In addition, the mapping operations
BUILD_MAP_UNPACK and BUILD_MAP_UNPACK_WITH_CALL
can be replaced with DICT_UPDATE and DICT_MERGE.

DICT_MERGE is like DICT_UPDATE but raises an exception for duplicate keys.

This change would not have much of an effect of performance, as the bytecodes listed are relatively rarely used, but shrinking the interpreter is always beneficial.

----------
components: Interpreter Core
messages: 359901
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: Handle unpacking of */** arguments and rvalues in the compiler
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39320>
_______________________________________

From report at bugs.python.org  Mon Jan 13 07:50:19 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 13 Jan 2020 12:50:19 +0000
Subject: [issue39320] Handle unpacking of */** arguments and rvalues in the
 compiler
In-Reply-To: <1578918490.54.0.342025462897.issue39320@roundup.psfhosted.org>
Message-ID: <1578919819.66.0.529223845454.issue39320@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +17388
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17984

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39320>
_______________________________________

From report at bugs.python.org  Mon Jan 13 08:34:20 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 13 Jan 2020 13:34:20 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578922460.58.0.0805618730073.issue39318@roundup.psfhosted.org>


Change by Ned Batchelder <ned at nedbatchelder.com>:


----------
keywords: +patch
pull_requests: +17389
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17985

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Mon Jan 13 08:44:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 13:44:04 +0000
Subject: [issue20443] __code__. co_filename should always be an absolute path
In-Reply-To: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za>
Message-ID: <1578923044.33.0.814032141599.issue20443@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17390
pull_request: https://github.com/python/cpython/pull/17986

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20443>
_______________________________________

From report at bugs.python.org  Mon Jan 13 08:57:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 13:57:20 +0000
Subject: [issue20443] __code__. co_filename should always be an absolute path
In-Reply-To: <1391048115.83.0.412883752117.issue20443@psf.upfronthosting.co.za>
Message-ID: <1578923840.54.0.252591473805.issue20443@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset c1ee6e5e9b87c9812c6745c1dd6c1788a984f9f9 by Victor Stinner in branch 'master':
bpo-20443: Update What's New In Python 3.9 (GH-17986)
https://github.com/python/cpython/commit/c1ee6e5e9b87c9812c6745c1dd6c1788a984f9f9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20443>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:07:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 14:07:29 +0000
Subject: [issue29282] Fused multiply-add: proposal to add math.fma()
In-Reply-To: <1484560897.19.0.0955404368118.issue29282@psf.upfronthosting.co.za>
Message-ID: <1578924449.23.0.930730947511.issue29282@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17391
stage: commit review -> patch review
pull_request: https://github.com/python/cpython/pull/17987

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29282>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:11:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 14:11:05 +0000
Subject: [issue29282] Fused multiply-add: proposal to add math.fma()
In-Reply-To: <1484560897.19.0.0955404368118.issue29282@psf.upfronthosting.co.za>
Message-ID: <1578924665.16.0.872318524022.issue29282@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I converted https://hg.python.org/cpython/rev/b33012ef1417 written by Mark Dickinson into a GitHub PR: PR 17987. I still expect tests failures. I plan to use the PR as a starting point to implement math.fma(). If tests continue to fail on some platforms, I plan to manually handle NaN and INF in the C code, before calling libc fma().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29282>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:18:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 14:18:07 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: main regrtest process
 killed by Signal 9
Message-ID: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

https://buildbot.python.org/all/#/builders/214/builds/152

...
0:08:21 load avg: 3.66 [240/420] test_wait3 passed -- running: test_multiprocessing_forkserver (1 min 51 sec)
0:08:22 load avg: 3.66 [241/420] test_uuid passed -- running: test_multiprocessing_forkserver (1 min 53 sec)
0:08:25 load avg: 3.53 [242/420] test_tuple passed -- running: test_multiprocessing_forkserver (1 min 55 sec)
0:08:32 load avg: 3.56 [243/420] test___all__ passed -- running: test_multiprocessing_forkserver (2 min 3 sec)
*** Signal 9
Stop.
make: stopped in /usr/home/buildbot/python/3.x.koobs-freebsd-9e36.nondebug/build
program finished with exit code 1
elapsedTime=519.823452

----------
components: Tests
messages: 359904
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: AMD64 FreeBSD Non-Debug 3.x: main regrtest process killed by Signal 9
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:20:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 14:20:32 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: main regrtest process
 killed by SIGKILL (Signal 9)
In-Reply-To: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>
Message-ID: <1578925232.87.0.924211000082.issue39321@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like Signal 9 is SIGKILL.

----------
title: AMD64 FreeBSD Non-Debug 3.x: main regrtest process killed by Signal 9 -> AMD64 FreeBSD Non-Debug 3.x: main regrtest process killed by SIGKILL (Signal 9)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:21:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 14:21:30 +0000
Subject: [issue39238] test_asyncio:
 test_cancel_make_subprocess_transport_exec() hangs randomly on PPC64LE Fedora
 3.x
In-Reply-To: <1578349019.82.0.0702143761935.issue39238@roundup.psfhosted.org>
Message-ID: <1578925290.83.0.78649949611.issue39238@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

AMD64 RHEL7 LTO + PGO 3.8:
https://buildbot.python.org/all/#/builders/83/builds/76

...
test_terminate (test.test_asyncio.test_subprocess.SubprocessFastWatcherTests) ... ok
Timeout (0:15:00)!
Thread 0x00007f070075a740 (most recent call first):
  File "/home/buildbot/buildarea/3.8.cstratak-RHEL7-x86_64.lto-pgo/build/Lib/selectors.py", line 468 in select
  File "/home/buildbot/buildarea/3.8.cstratak-RHEL7-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 1823 in _run_once
  File "/home/buildbot/buildarea/3.8.cstratak-RHEL7-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 570 in run_forever
  File "/home/buildbot/buildarea/3.8.cstratak-RHEL7-x86_64.lto-pgo/build/Lib/asyncio/base_events.py", line 603 in run_until_complete
  File "/home/buildbot/buildarea/3.8.cstratak-RHEL7-x86_64.lto-pgo/build/Lib/test/test_asyncio/test_subprocess.py", line 440 in test_cancel_make_subprocess_transport_exec
  File "/home/buildbot/buildarea/3.8.cstratak-RHEL7-x86_64.lto-pgo/build/Lib/unittest/case.py", line 633 in _callTestMethod

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39238>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:25:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 14:25:15 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: main regrtest process
 killed by SIGKILL (Signal 9)
In-Reply-To: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>
Message-ID: <1578925515.22.0.460473331856.issue39321@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Same error on https://buildbot.python.org/all/#builders/214/builds/148

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:25:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 14:25:42 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: main regrtest process
 killed by SIGKILL (Signal 9)
In-Reply-To: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>
Message-ID: <1578925542.15.0.772410306078.issue39321@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Same error https://buildbot.python.org/all/#builders/214/builds/138

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:25:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 14:25:47 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: main regrtest process
 killed by SIGKILL (Signal 9)
In-Reply-To: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>
Message-ID: <1578925547.35.0.46455196152.issue39321@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:26:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 14:26:48 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1578925608.18.0.16814014304.issue38323@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The test still hangs randomly. Can it be disabled or fixed?

s390x Debian 3.x:
https://buildbot.python.org/all/#builders/105/builds/167

test_close_dont_kill_finished (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... ok
Timeout (0:15:00)!
Thread 0x000003ffaa9f8700 (most recent call first):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/selectors.py", line 468 in select
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/asyncio/base_events.py", line 1852 in _run_once
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/asyncio/base_events.py", line 596 in run_forever
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/asyncio/base_events.py", line 629 in run_until_complete
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/test_subprocess.py", line 485 in test_close_kill_running
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 616 in _callTestMethod
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 659 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/case.py", line 719 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 122 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 122 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 122 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 122 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 122 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/suite.py", line 84 in __call__
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/unittest/runner.py", line 176 in run
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/support/__init__.py", line 2079 in _run_suite
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/support/__init__.py", line 2201 in run_unittest
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/runtest.py", line 209 in _test_module
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/runtest.py", line 234 in _runtest_inner2
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/runtest.py", line 270 in _runtest_inner
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/runtest.py", line 153 in _runtest
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/runtest.py", line 193 in runtest
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/main.py", line 318 in rerun_failed_tests
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/main.py", line 691 in _main
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/main.py", line 634 in main
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/libregrtest/main.py", line 712 in main
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/__main__.py", line 2 in <module>
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/runpy.py", line 86 in _run_code
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/runpy.py", line 193 in _run_module_as_main
test_close_kill_running (test.test_asyncio.test_subprocess.SubprocessMultiLoopWatcherTests) ... Makefile:1164: recipe for target 'buildbottest' failed
make: *** [buildbottest] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:34:54 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Jan 2020 14:34:54 +0000
Subject: [issue39320] Handle unpacking of */** arguments and rvalues in the
 compiler
In-Reply-To: <1578918490.54.0.342025462897.issue39320@roundup.psfhosted.org>
Message-ID: <1578926094.73.0.195467384625.issue39320@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39320>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:36:26 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 13 Jan 2020 14:36:26 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1578926185.99.0.723979160506.issue38323@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I'd like to spend time by reproducing the issue locally.
Please give me a few days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:37:41 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Mon, 13 Jan 2020 14:37:41 +0000
Subject: [issue39048] Change the lookup order of __aenter__ and __aexit__ for
 async with
In-Reply-To: <1576353517.6.0.763131039625.issue39048@roundup.psfhosted.org>
Message-ID: <1578926261.03.0.384124258283.issue39048@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
title: Reorder  __aenter__ & __aexit__ checks for async with statement -> Change the lookup order of __aenter__ and __aexit__ for async with

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39048>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:39:15 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Jan 2020 14:39:15 +0000
Subject: [issue29282] Fused multiply-add: proposal to add math.fma()
In-Reply-To: <1484560897.19.0.0955404368118.issue29282@psf.upfronthosting.co.za>
Message-ID: <1578926355.45.0.912016890972.issue29282@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> If tests continue to fail on some platforms, I plan to manually handle NaN and INF in the C code, before calling libc fma().

For Windows, you need to do much more than this: it's not just about handling NaNs and infinities, it's about reimplementing the entire function from scratch to give correctly rounded results. Without correctly-rounded results, there's very little point in having fma.

If it were a couple of niche platforms that gave bad results, then we could push this through. But it's Windows. :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29282>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:39:43 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Jan 2020 14:39:43 +0000
Subject: [issue39299] Improve test coverage for mimetypes module
In-Reply-To: <1578722796.76.0.475900715527.issue39299@roundup.psfhosted.org>
Message-ID: <1578926383.5.0.386044912152.issue39299@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:


New changeset d8efc1495194228c3a4cd472200275d6491d8e2d by Karthikeyan Singaravelan in branch 'master':
bpo-39299: Add more tests for mimetypes and its cli. (GH-17949)
https://github.com/python/cpython/commit/d8efc1495194228c3a4cd472200275d6491d8e2d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39299>
_______________________________________

From report at bugs.python.org  Mon Jan 13 09:53:17 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 13 Jan 2020 14:53:17 +0000
Subject: [issue29282] Fused multiply-add: proposal to add math.fma()
In-Reply-To: <1484560897.19.0.0955404368118.issue29282@psf.upfronthosting.co.za>
Message-ID: <1578927197.56.0.898296065927.issue29282@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay, looks like Windows is happy in the PR's continuous integration. If the buildbots are also happy, then I'm content to have this pushed through.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29282>
_______________________________________

From report at bugs.python.org  Mon Jan 13 10:17:08 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Jan 2020 15:17:08 +0000
Subject: [issue39322] Add gc.is_finalized to check if an object has been
 finalised by the gc
Message-ID: <1578928628.66.0.851687765453.issue39322@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Right now is not possible to check from the Python layer if an object with gc support has been already finalized by the GC (but has been resurrected). When implementing some callbacks for the gc in order to add advanced statistics, I have greatly missed a function like this to check if a certain object has been resurrected / the finalizer has been called.

----------
assignee: pablogsal
components: Interpreter Core
messages: 359914
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Add gc.is_finalized to check if an object has been finalised by the gc
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39322>
_______________________________________

From report at bugs.python.org  Mon Jan 13 10:19:17 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 13 Jan 2020 15:19:17 +0000
Subject: [issue39322] Add gc.is_finalized to check if an object has been
 finalised by the gc
In-Reply-To: <1578928628.66.0.851687765453.issue39322@roundup.psfhosted.org>
Message-ID: <1578928757.13.0.233707760744.issue39322@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +17392
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17989

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39322>
_______________________________________

From report at bugs.python.org  Mon Jan 13 11:08:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 16:08:27 +0000
Subject: [issue36710] Pass _PyRuntimeState as an argument rather than using
 the _PyRuntime global variable
In-Reply-To: <1556110680.79.0.127639989845.issue36710@roundup.psfhosted.org>
Message-ID: <1578931707.6.0.917944080894.issue36710@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I continued this work by passing tstate to internal C functions: bpo-38644.

I also added PyInterpreterState.runtime field, so it's now possible to retrieve the runtime from tstate:

    runtime = tstate->interp->runtime;

I wrote an article on passing tstate to internal C functions:

https://vstinner.github.io/cpython-pass-tstate.html

I consider that this issue is now done. I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36710>
_______________________________________

From report at bugs.python.org  Mon Jan 13 11:09:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 16:09:54 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1578931794.31.0.282977314491.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> One further step would be to change the VECTORCALL/FASTCALL calling convention to pass tstate. But I am not sure what is the risk to do that in Python 3.9? Cython uses FASTCALL internally for example.

I started a thread on python-dev:
https://mail.python.org/archives/list/python-dev at python.org/thread/PIXJAJPWKDGHSQD65VOO2B7FDLU2QLHH/

I also wrote an article on this issue, "Pass the Python thread state explicitly":
https://vstinner.github.io/cpython-pass-tstate.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Jan 13 11:26:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 16:26:58 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1578932818.38.0.771556100527.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17393
pull_request: https://github.com/python/cpython/pull/17990

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Jan 13 11:30:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 16:30:21 +0000
Subject: [issue39164] PyErr_GetExcInfo does not allow to retrieve for an
 arbitrary thread
In-Reply-To: <1577702198.9.0.00483910121214.issue39164@roundup.psfhosted.org>
Message-ID: <1578933021.37.0.320632536722.issue39164@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 3430c55417f59078ac397c343894a3ee82a39624 by Victor Stinner (Julien Danjou) in branch 'master':
bpo-39164: Add private _PyErr_GetExcInfo() function (GH-17752)
https://github.com/python/cpython/commit/3430c55417f59078ac397c343894a3ee82a39624


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39164>
_______________________________________

From report at bugs.python.org  Mon Jan 13 11:31:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 16:31:03 +0000
Subject: [issue39164] Add private _PyErr_GetExcInfo() function which accepts a
 tstate argument
In-Reply-To: <1577702198.9.0.00483910121214.issue39164@roundup.psfhosted.org>
Message-ID: <1578933063.88.0.858659146526.issue39164@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Julien Danjou.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: PyErr_GetExcInfo does not allow to retrieve for an arbitrary thread -> Add private _PyErr_GetExcInfo() function which accepts a tstate argument
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39164>
_______________________________________

From report at bugs.python.org  Mon Jan 13 11:42:19 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Jan 2020 16:42:19 +0000
Subject: [issue39323] Add test for imghdr cli
Message-ID: <1578933739.07.0.811706238675.issue39323@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

imghdr module has a cli that can display the image type for a given filename and also recurse through directories. I would like to propose following changes :

* Add tests for the imghdr cli.
* The cli uses hardcoded '/' separator in the end for directories this is a minor issue with windows where the separators are \ and the last separator is displayed with / like c:\Foo\Bar\Spam/ . Using os.sep can be a better option here.

I have a PR that I will add shortly for review.

----------
components: Tests
messages: 359919
nosy: xtreak
priority: normal
severity: normal
status: open
title: Add test for imghdr cli
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39323>
_______________________________________

From report at bugs.python.org  Mon Jan 13 12:10:31 2020
From: report at bugs.python.org (Chris Burr)
Date: Mon, 13 Jan 2020 17:10:31 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1578935431.71.0.235327809209.issue18233@roundup.psfhosted.org>


Change by Chris Burr <christopher.burr at cern.ch>:


----------
nosy: +chrisburr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Mon Jan 13 12:47:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 17:47:06 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1578937626.4.0.476352196154.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 2b1df4592e1691017414337514c6e378eb639498 by Victor Stinner in branch 'master':
bpo-38644: Pass tstate to _Py_FinishPendingCalls() (GH-17990)
https://github.com/python/cpython/commit/2b1df4592e1691017414337514c6e378eb639498


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Jan 13 13:04:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 18:04:03 +0000
Subject: [issue29282] Fused multiply-add: proposal to add math.fma()
In-Reply-To: <1484560897.19.0.0955404368118.issue29282@psf.upfronthosting.co.za>
Message-ID: <1578938643.77.0.628140940293.issue29282@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> For Windows, you need to do much more than this: it's not just about handling NaNs and infinities, it's about reimplementing the entire function from scratch to give correctly rounded results. Without correctly-rounded results, there's very little point in having fma.

Would it make sense to only make the function available on non-Windows platforms? As we do for other Unix-only functions in the os module. Maybe even skip more platforms if they provide a broken implementation.

We could implement a test suite in configure to decide if fma() fits our requirements or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29282>
_______________________________________

From report at bugs.python.org  Mon Jan 13 13:04:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 18:04:44 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1578938684.7.0.654329848893.issue26317@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Mon Jan 13 13:05:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 18:05:21 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1578938721.77.0.170541070546.issue26317@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +corona10 -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Mon Jan 13 13:16:58 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 13 Jan 2020 18:16:58 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1578939418.45.0.599172677016.issue26317@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The progress was the PR.  I just fixed the merge conflicts, I believe correctly.  Please test and review.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Mon Jan 13 13:19:58 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 13 Jan 2020 18:19:58 +0000
Subject: [issue26317] Build Problem with GCC + Macintosh OS X 10.11 El Capitain
In-Reply-To: <1454992584.65.0.198275659625.issue26317@psf.upfronthosting.co.za>
Message-ID: <1578939598.78.0.493830484309.issue26317@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks, Terry. I'll look at it shortly.

----------
assignee:  -> ned.deily
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26317>
_______________________________________

From report at bugs.python.org  Mon Jan 13 13:25:20 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jan 2020 18:25:20 +0000
Subject: [issue39299] Improve test coverage for mimetypes module
In-Reply-To: <1578722796.76.0.475900715527.issue39299@roundup.psfhosted.org>
Message-ID: <1578939920.78.0.583608595711.issue39299@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17394
pull_request: https://github.com/python/cpython/pull/17991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39299>
_______________________________________

From report at bugs.python.org  Mon Jan 13 13:25:28 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jan 2020 18:25:28 +0000
Subject: [issue39299] Improve test coverage for mimetypes module
In-Reply-To: <1578722796.76.0.475900715527.issue39299@roundup.psfhosted.org>
Message-ID: <1578939928.49.0.790843956674.issue39299@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17395
pull_request: https://github.com/python/cpython/pull/17992

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39299>
_______________________________________

From report at bugs.python.org  Mon Jan 13 13:33:14 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 13 Jan 2020 18:33:14 +0000
Subject: [issue39323] Add test for imghdr cli
In-Reply-To: <1578933739.07.0.811706238675.issue39323@roundup.psfhosted.org>
Message-ID: <1578940394.39.0.0696523093067.issue39323@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch
pull_requests: +17396
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17993

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39323>
_______________________________________

From report at bugs.python.org  Mon Jan 13 13:49:12 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Jan 2020 18:49:12 +0000
Subject: [issue39296] Windows register keys
In-Reply-To: <1578695287.77.0.549625073253.issue39296@roundup.psfhosted.org>
Message-ID: <1578941352.02.0.217666004062.issue39296@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

You should read the version number from the Version or SysVersion values, rather than from the tag.

Having -32 in the key name is a compatibility requirement. Without it, if you installed 32-bit and 64-bit versions for the current user (which is now the default), they would overwrite each other.

The Wow6432Node key is due to Windows, not Python. We don't decide the name or when it is used, and Windows determined that HKEY_CURRENT_USER is not subject to registry redirection. That's why you don't see it there.

Hope that helps clarify what's going on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39296>
_______________________________________

From report at bugs.python.org  Mon Jan 13 13:52:15 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 13 Jan 2020 18:52:15 +0000
Subject: [issue39293] Windows 10 64-bit needs reboot
In-Reply-To: <1578690694.46.0.197073018811.issue39293@roundup.psfhosted.org>
Message-ID: <1578941535.11.0.910057413771.issue39293@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Can you show some of these errors?

Certainly any existing console windows (cmd/PowerShell) will not have their PATH variables updated - that's by design - but there should not be anything else in Python 3.8 that requires a reboot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39293>
_______________________________________

From report at bugs.python.org  Mon Jan 13 14:17:42 2020
From: report at bugs.python.org (Juraj Sukop)
Date: Mon, 13 Jan 2020 19:17:42 +0000
Subject: [issue29282] Fused multiply-add: proposal to add math.fma()
In-Reply-To: <1484560897.19.0.0955404368118.issue29282@psf.upfronthosting.co.za>
Message-ID: <1578943062.0.0.518099108594.issue29282@roundup.psfhosted.org>


Juraj Sukop <juraj.sukop at gmail.com> added the comment:

FWIW, there is a new implementation of FMA [1] which is licensed very permissively [2]. Perhaps it could be used here as well..?

[1] https://github.com/smasher164/fma
[2] https://github.com/smasher164/fma/commit/4e85d2388c7d4d850be12df918f9431ca687f57a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29282>
_______________________________________

From report at bugs.python.org  Mon Jan 13 14:24:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 19:24:16 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578943456.01.0.708464588883.issue39310@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9362f8526e42157baf27df982b16f23f212c3c3a by Victor Stinner in branch '3.8':
bpo-39310: Update sys.float_info documentation (GH-17982)
https://github.com/python/cpython/commit/9362f8526e42157baf27df982b16f23f212c3c3a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Mon Jan 13 14:24:49 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jan 2020 19:24:49 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578943489.48.0.353780282785.issue39310@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17397
pull_request: https://github.com/python/cpython/pull/17994

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Mon Jan 13 14:27:33 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 13 Jan 2020 19:27:33 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1578943653.42.0.350107039367.issue38323@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

FYI, I'm able to reproduce the hang by running "python -m test -F test_asyncio -m test_close_kill_running".

Working on the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Mon Jan 13 14:30:04 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 13 Jan 2020 19:30:04 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578943804.7.0.387491480914.issue39310@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dfe159ca552870f801e34cc57e9bb7d6836ce7df by Miss Islington (bot) in branch '3.7':
bpo-39310: Update sys.float_info documentation (GH-17982)
https://github.com/python/cpython/commit/dfe159ca552870f801e34cc57e9bb7d6836ce7df


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Mon Jan 13 14:34:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 19:34:40 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578944080.84.0.727333792467.issue39259@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a190e2ade1a704a6b5a94464a0a19b140c7dd031 by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-39259: ftplib.FTP/FTP_TLS now reject timeout = 0 (GH-17959)
https://github.com/python/cpython/commit/a190e2ade1a704a6b5a94464a0a19b140c7dd031


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Mon Jan 13 14:53:40 2020
From: report at bugs.python.org (Ryan Batchelder)
Date: Mon, 13 Jan 2020 19:53:40 +0000
Subject: [issue39324] Add mimetype for extension .md (markdown)
Message-ID: <1578945220.79.0.19370550446.issue39324@roundup.psfhosted.org>


New submission from Ryan Batchelder <ryanbatch at gmail.com>:

I would like to propose that the mimetype for markdown files ending in .md to text/markdown is included in the mimetypes library. This is registered here: https://www.iana.org/assignments/media-types/text/markdown

----------
messages: 359931
nosy: Ryan Batchelder
priority: normal
severity: normal
status: open
title: Add mimetype for extension .md (markdown)
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/issue39324>
_______________________________________

From report at bugs.python.org  Mon Jan 13 15:04:32 2020
From: report at bugs.python.org (Ryan Batchelder)
Date: Mon, 13 Jan 2020 20:04:32 +0000
Subject: [issue39324] Add mimetype for extension .md (markdown)
In-Reply-To: <1578945220.79.0.19370550446.issue39324@roundup.psfhosted.org>
Message-ID: <1578945872.09.0.881831378001.issue39324@roundup.psfhosted.org>


Change by Ryan Batchelder <ryanbatch at gmail.com>:


----------
keywords: +patch
pull_requests: +17398
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17995

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39324>
_______________________________________

From report at bugs.python.org  Mon Jan 13 15:16:51 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 13 Jan 2020 20:16:51 +0000
Subject: [issue28166] WindowsConsoleIO misbehavior when Ctrl+C is ignored
In-Reply-To: <1473927025.25.0.183534906845.issue28166@psf.upfronthosting.co.za>
Message-ID: <1578946611.8.0.0429930207291.issue28166@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

On second thought, I think the fact that the console leaves the previously entered text on the line is ugly and confusing. The text isn't in the input buffer, so it won't be read. Yet there's no way for the user to even clear it -- not by escape or backspace. I think the user is better served if we settle for less. 

We can try to write a CRLF to the input buffer via WriteConsoleInputW and then continue. The next read will return immediately, and we'll drop out of the loop, retaining however much was read prior to the canceled read. The console's cooked read will take care of advancing the cursor to the next line for us. If WriteConsoleInputW fails (e.g. the file is "CON", opened with only generic-read access), we can fall back on directly writing "\r\n" to the buffer instead of continuing. However this won't advance the cursor to the next line.

I think we should also merge in the CancelSynchronousIo abort case, i.e. where n_read is still the initial value of (DWORD)-1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28166>
_______________________________________

From report at bugs.python.org  Mon Jan 13 15:59:14 2020
From: report at bugs.python.org (Aurora)
Date: Mon, 13 Jan 2020 20:59:14 +0000
Subject: [issue39319] ntpath module must not be available on POSIX platforms
In-Reply-To: <1578913081.93.0.570366653364.issue39319@roundup.psfhosted.org>
Message-ID: <1578949154.38.0.800288179916.issue39319@roundup.psfhosted.org>


Aurora <auroralanes at pm.me> added the comment:

@eryksun So modify the documentation to note that they're operable on both platforms.
I've seen that ntpath worked on my Linux system, but the documentation was misleading.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39319>
_______________________________________

From report at bugs.python.org  Mon Jan 13 16:14:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 13 Jan 2020 21:14:12 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578950052.3.0.702482993348.issue39318@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This issue is more complex. I am working on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Mon Jan 13 17:08:47 2020
From: report at bugs.python.org (=?utf-8?q?J=C3=B6rn_Heissler?=)
Date: Mon, 13 Jan 2020 22:08:47 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578953327.74.0.859963831692.issue39318@roundup.psfhosted.org>


Change by J?rn Heissler <launchpad2019 at tutnicht.de>:


----------
nosy: +joernheissler

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Mon Jan 13 17:51:57 2020
From: report at bugs.python.org (Jack O'Connor)
Date: Mon, 13 Jan 2020 22:51:57 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1578955917.78.0.41929866395.issue39298@roundup.psfhosted.org>


Jack O'Connor <oconnor663 at gmail.com> added the comment:

I'm in the middle of adding some Rust bindings to the C implementation in github.com/BLAKE3-team/BLAKE3, so that `cargo test` and `cargo bench` can cover both. Once that's done, I'll follow up with benchmark numbers from my laptop (Kaby Lake i5-8250U, also AVX2 with no AVX-512). For benchmark numbers with AVX-512 support, see the Performance section of the BLAKE3 paper (https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blake3.pdf). Larry, what processor did you run your benchmarks on?

Also, is there anything currently in CPython that does dispatch based on runtime CPU feature detection? Is this something that BLAKE3 should do for itself, or is there existing machinery that we'd want to integrate with?

----------
nosy: +oconnor663

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Mon Jan 13 18:05:01 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 13 Jan 2020 23:05:01 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578956701.76.0.565427556966.issue39310@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Can I just say that "ulp" is totally non-obvious what that even means unless you have a specific math background?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Mon Jan 13 18:08:14 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 13 Jan 2020 23:08:14 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578956894.06.0.131865852339.issue39310@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

And sorry if that last response from me came off as grumpy; it wasn't meant to. I just had no clue what you were adding based on the name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Mon Jan 13 18:32:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 13 Jan 2020 23:32:50 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1578958370.7.0.0735973772593.issue39310@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Can I just say that "ulp" is totally non-obvious what that even means unless you have a specific math background?

The math.ulp() documentation explicitly says: https://docs.python.org/dev/library/math.html#math.ulp

   ULP stands for ?Unit in the Last Place?.

The term "ulp" is commonly used when talking about IEEE 754 floating point numbers. It is used in numpy and Java for example.

test_math.py already had an ulp() function which was a pure Python implementation.

The term is also commonly used in math articles.

If you don't know the term "ulp", it's likely a *good thing*. You didn't have to suffer with rounding issues :-D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Mon Jan 13 18:51:49 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 13 Jan 2020 23:51:49 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578956701.76.0.565427556966.issue39310@roundup.psfhosted.org>
Message-ID: <20200113235141.GU839@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I hear what you are saying, but "ulp" is the standard term of art. Sure 
it is non-obvious until you learn it, just like other technical terms 
like "mro", "abc" or "ast".

Mathematics and numeric programming are rife with short names that are 
non-obvious and often ambiguous with "ordinary" words, e.g.

    sin, tan, log, nan

to mention just a few. "ulp" is a technical, and subtle, concept to 
grasp, and no easier to understand when spelled out as "unit in last 
place".

At least ulp is a TLA from English, unlike (say) "sine" which ultimately 
derives from the Sanscrit word "jya" (chord), via Arabic and Latin. If 
you've ever wondered if the trigonometric sin() function is related to 
the sinus cavities in your nose, yes it is :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Mon Jan 13 18:52:19 2020
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 13 Jan 2020 23:52:19 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1578959539.2.0.659370646953.issue39298@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

According to my order details it is a "8th Generation Intel Core i7-8650U".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Mon Jan 13 20:24:01 2020
From: report at bugs.python.org (Irv Kalb)
Date: Tue, 14 Jan 2020 01:24:01 +0000
Subject: [issue39325] Original window focus when opening IDLE by double
 clicking Python file Mac
Message-ID: <1578965041.32.0.467720102462.issue39325@roundup.psfhosted.org>


New submission from Irv Kalb <Irv at furrypants.com>:

I have my Mac to open ".py" files with IDLE.  If IDLE is not running, and I double click on a Python file, the Shell window opens, then the Python file I clicked on opens in front, but the Shell has keyboard focus.  In order to edit or run the source file, I must click in that window to give it focus.

I have made a two minute video that is available here as a private video:

https://youtu.be/Fs_ZAiej-WI

Thanks for your consideration.

Irv

----------
assignee: terry.reedy
components: IDLE
messages: 359942
nosy: IrvKalb, terry.reedy
priority: normal
severity: normal
status: open
title: Original window focus when opening IDLE by double clicking Python file Mac
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39325>
_______________________________________

From report at bugs.python.org  Mon Jan 13 22:29:03 2020
From: report at bugs.python.org (Kubilay Kocak)
Date: Tue, 14 Jan 2020 03:29:03 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: main regrtest process
 killed by SIGKILL (Signal 9)
In-Reply-To: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>
Message-ID: <1578972543.29.0.918318244522.issue39321@roundup.psfhosted.org>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

Identified a kernel/userland mismatch which may have caused this. Have restarted the server and worker, and will rebuild https://buildbot.python.org/all/#/builders/214/builds/152

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Mon Jan 13 22:55:18 2020
From: report at bugs.python.org (Kubilay Kocak)
Date: Tue, 14 Jan 2020 03:55:18 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: main regrtest process
 killed by SIGKILL (Signal 9)
In-Reply-To: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>
Message-ID: <1578974118.61.0.522677937855.issue39321@roundup.psfhosted.org>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

Rebuilding now

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Mon Jan 13 23:52:26 2020
From: report at bugs.python.org (Divyansh tiwari)
Date: Tue, 14 Jan 2020 04:52:26 +0000
Subject: [issue39326] Python-3.8.1 "test_importlib" failed
Message-ID: <1578977546.19.0.0039726161306.issue39326@roundup.psfhosted.org>


New submission from Divyansh tiwari <divyansh.tiwari007 at gmail.com>:

Python-3.8.1 after "make test" command in Ubuntu terminal report an error saying "test_importlib" failed.

= Tests result: FAILURE then FAILURE ==

1 test failed:
    test_importlib

1 re-run test:
    test_importlib

==========================================
I re-ran the test my the command make test TESTOPTS="-v test_importlib"

but again result in failed

----------
components: Build
messages: 359945
nosy: Divyansh_tiwari
priority: normal
severity: normal
status: open
title: Python-3.8.1 "test_importlib" failed
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39326>
_______________________________________

From report at bugs.python.org  Tue Jan 14 00:46:16 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 14 Jan 2020 05:46:16 +0000
Subject: [issue39326] Python-3.8.1 "test_importlib" failed
In-Reply-To: <1578977546.19.0.0039726161306.issue39326@roundup.psfhosted.org>
Message-ID: <1578980776.59.0.0227457234584.issue39326@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please attach the output log of the test?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39326>
_______________________________________

From report at bugs.python.org  Tue Jan 14 00:54:28 2020
From: report at bugs.python.org (Matthew Newville)
Date: Tue, 14 Jan 2020 05:54:28 +0000
Subject: [issue39295] usage of bitfields in ctypes structures changed between
 3.7.5 and 3.7.6
In-Reply-To: <1578694567.2.0.498689301236.issue39295@roundup.psfhosted.org>
Message-ID: <1578981268.84.0.724553152494.issue39295@roundup.psfhosted.org>


Matthew Newville <matt.newville at gmail.com> added the comment:

So, again, I'm trying to understand what the best workaround for this change is.  I asked "can this workaround be improved" twice and got no reply, while getting plenty of responses to questions about the development process.  I take this to mean that the workaround we have is the best available. That's unfortunate.

>> it appears that an old, poorly verified bug report
>
> Why do you say the bug report is poorly verified? The libffi maintainers
> accept it is an issue.
>
> https://github.com/libffi/libffi/issues/33

Well, it is more than six years old. It did not appear that lots of people were saying "yeah me too, please fix!".  Maybe I missed those calls of urgency? 


>> inspired a change that was actually not well tested and so incorrectly 
>> broke valid code without deprecation. Trying to be as polite as possible, >> this appears to indicate a poor testing process, if not a poor 
>> understanding of the actual code in question.

> Well, the original developer of ctypes is no longer involved in maintaining > it. Those of us who try to address ctypes issues are perhaps not as well-
> versed in the code as the original developer and maintainer, but we do our
> best. This of course applies to other areas in CPython, and many other
> projects besides.

I think you are agreeing with me ;).  That worries me.

> The change was accompanied by tests, which have been no doubt found 
> wanting, 

It appears that the change was *intended* to fix a problem with Unions, but had the unintended consequence of not allowing any structures with bitfields. That suggests that the ctypes tests don't include structures with bitfields, These seem sort of common to me, so it appears that testing of ctypes is far less comprehensive than I had imagined.

> but do *you* write software which guarantees no bugs ever in released 
> versions? 

Of course not, and that is not the expectation.  It's a bit alarming to hear Python devs be so defensive and using such straw man arguments.  What is expected is that working code does not break without warning or deprecation and that testing is sort of complete. It is expected that when changes unintentionally break working code that the devs take a step back and say "wait, how did that happen? what are we not testing that our users are expecting to work?". It is also expected that problems are acknowledged and fixed in a timely manner.  

And yes, to the extent possible, we try to do those things. With Py 3.7.6 available and installed with `conda update`, this break was a very urgent problem (library failed to import!) for us and our downstream users. Within 36 hours of the first report of the problem, we had a workaround verified and pushed to PyPI. The response of Python team to the original problem and to the unintended breakage were much slower.  
 

> Using your example above, I will look into what was missed 
> and try to improve the checking. The underlying libffi issue is a real
> one. The change wasn't introduced in a cavalier manner, as you seem to
> be suggesting.

Well, the change did wait six years from the first report and yet did not include a deprecation cycle. If that TypeError had been a Warning for a few releases, you would have no doubt heard questions like "why is this working code going to be deprecated" instead of "why did Python break by library".

> Do you regularly test your code with Python alpha and beta versions? 
> I ask because I may reinstate the check for Python 3.9 after seeing what
> false-positive cases were missed here. Python 3.9 is at alpha 2 level 
> right now. Continued feedback could help to minimise the chances of 
> future surprises.

I have never tested an `alpha` versions, and not used many `beta` version either (code development is not actually my full-time job) -- certainly not in the Python 3 series. I have trusted the Python devels.  This has worked well for many years and Python versions. But that trust, especially concerning ctypes, is diminished (a structure with bitfields was unexpected usage??) and we probably should be testing beta versions regularly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39295>
_______________________________________

From report at bugs.python.org  Tue Jan 14 00:56:52 2020
From: report at bugs.python.org (Aurora)
Date: Tue, 14 Jan 2020 05:56:52 +0000
Subject: [issue39314] Autofill the closing paraenthesis during auto-completion
 for functions which accept no arguments at all
In-Reply-To: <1578846697.93.0.381295981609.issue39314@roundup.psfhosted.org>
Message-ID: <1578981412.33.0.630154432495.issue39314@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39314>
_______________________________________

From report at bugs.python.org  Tue Jan 14 01:01:52 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Jan 2020 06:01:52 +0000
Subject: [issue39295] usage of bitfields in ctypes structures changed between
 3.7.5 and 3.7.6
In-Reply-To: <1578694567.2.0.498689301236.issue39295@roundup.psfhosted.org>
Message-ID: <1578981712.42.0.113203177062.issue39295@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
keywords: +3.7regression, 3.8regression
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39295>
_______________________________________

From report at bugs.python.org  Tue Jan 14 01:36:07 2020
From: report at bugs.python.org (Carl Harris)
Date: Tue, 14 Jan 2020 06:36:07 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578983767.83.0.499523372111.issue39318@roundup.psfhosted.org>


Change by Carl Harris <elgoogemail2007 at gmail.com>:


----------
nosy: +hitbox

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Tue Jan 14 01:40:15 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Jan 2020 06:40:15 +0000
Subject: [issue39160] ./configure --help has inconsistencies in style
In-Reply-To: <1577677504.15.0.780834896909.issue39160@roundup.psfhosted.org>
Message-ID: <1578984015.4.0.803389719767.issue39160@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 2de064e6305008d16571a21e5f0c178e62e81f27 by Ned Deily (Anthony Shaw) in branch 'master':
bpo-39160 Align the verbs, grammar and defaults for `./configure --help` (GH-17747)
https://github.com/python/cpython/commit/2de064e6305008d16571a21e5f0c178e62e81f27


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39160>
_______________________________________

From report at bugs.python.org  Tue Jan 14 01:45:18 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 14 Jan 2020 06:45:18 +0000
Subject: [issue39273] ncurses does not include BUTTON5_* constants
In-Reply-To: <1578553141.45.0.141104357774.issue39273@roundup.psfhosted.org>
Message-ID: <1578984318.14.0.321842226003.issue39273@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +17400
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17996

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39273>
_______________________________________

From report at bugs.python.org  Tue Jan 14 01:46:35 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 14 Jan 2020 06:46:35 +0000
Subject: [issue39273] ncurses does not include BUTTON5_* constants
In-Reply-To: <1578553141.45.0.141104357774.issue39273@roundup.psfhosted.org>
Message-ID: <1578984395.91.0.0979048835599.issue39273@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
versions:  -Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39273>
_______________________________________

From report at bugs.python.org  Tue Jan 14 02:01:28 2020
From: report at bugs.python.org (Ajay Tripathi)
Date: Tue, 14 Jan 2020 07:01:28 +0000
Subject: [issue39283] Add ability to inherit unittest arguement parser
In-Reply-To: <1578630738.78.0.369523186494.issue39283@roundup.psfhosted.org>
Message-ID: <1578985288.37.0.543502426219.issue39283@roundup.psfhosted.org>


Ajay Tripathi <ajay39in at gmail.com> added the comment:

Hi,

Thanks for your response, here is a code sample of what I am doing right now:

```
import unittest
import sys

class MyTest(unittest.TestCase):

    def __init__(self, testName, extraArg):
        super(MyTest, self).__init__(testName)
        self.myExtraArg = extraArg

    def test_something(self):
        print(self.myExtraArg)

extraArg = sys.argv.pop()
suite = unittest.TestSuite()
suite.addTest(MyTest('test_something', extraArg))
unittest.TextTestRunner(verbosity=2).run(suite)
```

It works.
However, this can be cumbersome if there are a lot of "extraArgs" and MyTestClasses.
Especically, if there is an existing argparser function existing that is used in the program, re-writing the code for passing args in another way for unittest doesn't seem ideal.


Ideally, I think something like this may work perfectly:

```
import unittest


class SomethingLikeInheritedUnitest(unittest.TestProgram):
    # parent_parser is used here: https://github.com/python/cpython/blob/master/Lib/unittest/main.py#L162
    parent = super().createParentArgParserAndReturnIt()
    parser = argparse.ArgumentParser(parents=[parent])
    parser.add_argument('--myarg1', ...)
    parser.add_argument('--myarg2', ...)
    return parser
```

Now the parser may be exposed to user's MyTest class and they can use
arguements as: `paser.myarg1`


Note: I am not certain this may be the way to go about it, there may be a better way, infact, I've not even had the time to read the entire code. :-( 
I am only trying to point out is that the ability to add `myarg1` in the parent_parser may be useful at times.

Hope this makes the point a bit more clear. If I have misunderstood something please correct me.



Thank You,
Ajay Tripathi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39283>
_______________________________________

From report at bugs.python.org  Tue Jan 14 02:12:22 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Jan 2020 07:12:22 +0000
Subject: [issue39160] ./configure --help has inconsistencies in style
In-Reply-To: <1577677504.15.0.780834896909.issue39160@roundup.psfhosted.org>
Message-ID: <1578985942.43.0.770819174761.issue39160@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39160>
_______________________________________

From report at bugs.python.org  Tue Jan 14 02:48:03 2020
From: report at bugs.python.org (Kubilay Kocak)
Date: Tue, 14 Jan 2020 07:48:03 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: main regrtest process
 killed by SIGKILL (Signal 9)
In-Reply-To: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>
Message-ID: <1578988083.02.0.209867488993.issue39321@roundup.psfhosted.org>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

Looks OK now: https://buildbot.python.org/all/#/builders/214

If it fails again in the same manner, please re-open

----------
assignee:  -> koobs
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Tue Jan 14 02:50:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 07:50:06 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578988206.04.0.465532475981.issue39259@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 62e3973395fb9fab2eb8f651bcd0fea4e695e1cf by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-39259: smtp.SMTP/SMTP_SSL now reject timeout = 0 (GH-17958)
https://github.com/python/cpython/commit/62e3973395fb9fab2eb8f651bcd0fea4e695e1cf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Tue Jan 14 02:50:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 07:50:46 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578988246.42.0.0413915463003.issue39259@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Can we now close this issue? Or is there still something to do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Tue Jan 14 02:51:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 07:51:34 +0000
Subject: [issue39321] AMD64 FreeBSD Non-Debug 3.x: main regrtest process
 killed by SIGKILL (Signal 9)
In-Reply-To: <1578925087.43.0.642221025557.issue39321@roundup.psfhosted.org>
Message-ID: <1578988294.47.0.591418736932.issue39321@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Identified a kernel/userland mismatch which may have caused this. Have restarted the server and worker, and will rebuild https://buildbot.python.org/all/#/builders/214/builds/152

Aha, interesting bug. Thanks for fixing it ;-)

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39321>
_______________________________________

From report at bugs.python.org  Tue Jan 14 03:10:54 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Jan 2020 08:10:54 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1578989454.02.0.0156112017834.issue39259@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> Can we now close this issue? Or is there still something to do?

There is no case on xxlib series except LMTP.
I am going to open a new issue about LMTP.
So let's close this :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Tue Jan 14 03:14:25 2020
From: report at bugs.python.org (yang)
Date: Tue, 14 Jan 2020 08:14:25 +0000
Subject: [issue36078] argparse: positional with type=int,
 default=SUPPRESS raise ValueError
In-Reply-To: <1550845114.74.0.376208054151.issue36078@roundup.psfhosted.org>
Message-ID: <1578989665.47.0.272868367103.issue36078@roundup.psfhosted.org>


yang <fhsxfhsx at 126.com> added the comment:

I ran into the same issue and looked into the code, and found it more complicated than I thought. The more I went on, more issues occur. I wonder if I should open a new issue, but I will first comment here. If you feel like this should be a new issue, I will open one then. And I apologize in advance for possible vaguenesses in this comment because I modified it several times as I explored the code and found more issues. (also because of my poor English):)

It seems the issue happens only on positional arguments but not optional ones. Empty optional arguments will not call `take_action` and default values are handled and converted after consuming all arguments.

It also leads to inconsistancy between positional and optional arguments behaviour. Positional arguments always go through `take_action`, but optional arguments don't if an argument doesn't appear.

This inconsistancy causes another I think is strange behaviour,

    parser = ArgumentParser()
    parser.add_argument('i', action='count')
    parser.parse_args([])

got

    Namespace(i=1)

On the other hand, in `_get_values` function, `_check_value` is called to handle `choices=`, but there is no such guard for optional arguments, which means,

    parser = ArgumentParser()
    parser.add_argument('-i', nargs='?', type=int, default='2', choices=[1])
    parser.parse_args([])

doesn't raise an error.

Besides Paul's two instructive solutions, I think it better to make both sides behave the same. However, I found things seem not that simple.

First, ZERO_OR_MORE, no default value, positional arguments have `required=True` by default, but

    parser.add_argument('foo', nargs='*')
    parser.parse_args([])

got no problems. So it at least appears not required. (The document says `required` is only for optionals, so I guess it's just a implementation level but not a user level thing)

Second, the last case above gives

    Namespace(foo=[])

which seems logically incorrect or at least controversial, because the default is not set and you give no arguments, how does this list come? The document says nothing about the case (it's true it's a very corner one) and it also differs from the optional arguments case which gives

    Namespace(foo=None)

A walk around which doesn't change it is possible and I've written a patch fixing it.
And I'm not sure what we usually do if I propose to make them give the same result, is a PEP needed or I just raise a discussion about it? The change might break current code.

----------
nosy: +fhsxfhsx

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36078>
_______________________________________

From report at bugs.python.org  Tue Jan 14 03:51:04 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 14 Jan 2020 08:51:04 +0000
Subject: [issue39295] usage of bitfields in ctypes structures changed between
 3.7.5 and 3.7.6
In-Reply-To: <1578694567.2.0.498689301236.issue39295@roundup.psfhosted.org>
Message-ID: <1578991864.01.0.582493920357.issue39295@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The change has now been reverted, including on 3.8 and 3.7, so I think that this issue can be closed. Any naysayers?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39295>
_______________________________________

From report at bugs.python.org  Tue Jan 14 04:07:54 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Jan 2020 09:07:54 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578992874.64.0.901231954158.issue39318@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Problems:

1. In general, it is hard to avoid leaks because an exception like KeyboardInterrupt or MemoryError can be raised virtually anywhere, even before we save a file descriptor. We may rewrite the code so that it will use few simple bytecode instructions and disable interruption before these instructions. This may solve the problem in CPython, but alternate implementation will need to handle this theirself.

2. It is not safe to close a file descriptor if io.open() is failed, because it can already be closed in io.open(), and we do not know where it was closed or no. It can be solved by using the opener argument, but we will need to patch the name attribute of the file returned by io.open(), and it is not easy, because the type of the result of io.open() depends on the mode and buffering arguments, and only FileIO has writable name attribute. This will need additional complex code. We can also change the behavior of io.open(), make it either always closing fd or never closing it in case of error. But this will break working code, or introduce leaks in working code, so such change cannot be backported. In any case we should revisit all other cases of using io.open() with an open file descriptor in the stdlib (including TemporaryFile).

3. I afraid that removing a file while the file descriptor is open may not work on Windows. Seems this case is not well tested.

As for using `except Exception` instead of `except BaseException`, it is better to use the later, or even the bare `except`.

I worked on this issue yesterday, but then found new problems, it will take several days or weeks to solve them. As a workaround I suggest to skip temporary the test which monkeypatches _TemporaryFileWrapper.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Tue Jan 14 04:12:22 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 14 Jan 2020 09:12:22 +0000
Subject: [issue39207] concurrent.futures.ProcessPoolExecutor does not properly
 reap jobs and spawns too many workers
In-Reply-To: <1578087844.56.0.81762061225.issue39207@roundup.psfhosted.org>
Message-ID: <1578993142.91.0.885703664123.issue39207@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Uh, my understanding "But ProcessPoolExecutor starts worker processes on demand from old." was wrong.

I think this should be fixed like ThreadPoolExecutor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39207>
_______________________________________

From report at bugs.python.org  Tue Jan 14 04:13:00 2020
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 14 Jan 2020 09:13:00 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1578993180.88.0.960212400019.issue39318@roundup.psfhosted.org>


Albert Zeyer <albzey at googlemail.com> added the comment:

Why is `except BaseException` better than `except Exception` here? With `except Exception`, you will never run into the problem of possibly closing the fd twice. This is the main important thing which we want to fix here. This is more important than missing maybe to close it at all, or unlink it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Tue Jan 14 04:43:18 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Tue, 14 Jan 2020 09:43:18 +0000
Subject: [issue39207] concurrent.futures.ProcessPoolExecutor does not properly
 reap jobs and spawns too many workers
In-Reply-To: <1578087844.56.0.81762061225.issue39207@roundup.psfhosted.org>
Message-ID: <1578994998.22.0.514475272015.issue39207@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I think this should be fixed like ThreadPoolExecutor.

Are there are any downsides or complications with changing this behavior for ProcessPoolExecutor to consider, such as what I mentioned above? From my understanding, there would be a performance penalty associated with spawning the processes on-demand as opposed to the current behavior of spawning *max_workers* processes at the same time, and using each of them as needed.

Also, I think it's worth considering the following: do the same arguments for changing the behavior for ThreadPoolExecutor also apply to ProcessPoolExecutor? Although they share the same executor API, they have rather different use cases.

That being said, if it's decided that we do want to make this behavior consistent with ThreadPoolExecutor, I would be willing to look into implementing it. I just want to make sure that it's carefully considered first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39207>
_______________________________________

From report at bugs.python.org  Tue Jan 14 04:45:52 2020
From: report at bugs.python.org (Peter Liedholm)
Date: Tue, 14 Jan 2020 09:45:52 +0000
Subject: [issue39327] shutil.rmtree using vagrant synched folder fails
Message-ID: <1578995152.92.0.0617677010821.issue39327@roundup.psfhosted.org>


New submission from Peter Liedholm <peterfromswe884 at gmail.com>:

Python 3.6.9
Ubuntu 18.04
python3 -c 'import shutil; shutil.rmtree("1a")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.6/shutil.py", line 486, in rmtree
    _rmtree_safe_fd(fd, path, onerror)
  File "/usr/lib/python3.6/shutil.py", line 424, in _rmtree_safe_fd
    _rmtree_safe_fd(dirfd, fullname, onerror)
  File "/usr/lib/python3.6/shutil.py", line 424, in _rmtree_safe_fd
    _rmtree_safe_fd(dirfd, fullname, onerror)
  File "/usr/lib/python3.6/shutil.py", line 428, in _rmtree_safe_fd
    onerror(os.rmdir, fullname, sys.exc_info())
  File "/usr/lib/python3.6/shutil.py", line 426, in _rmtree_safe_fd
    os.rmdir(name, dir_fd=topfd)
OSError: [Errno 26] Text file busy: '4a'
-----------------
Reproduction method
mkdir synched_folder\1a\2a\3a\4a
mkdir synched_folder\1a\2b\3a\4a
mkdir synched_folder\1b\2a\3a\4a
choco install vagrant
Save Vagrantfile in empty folder
vagrant box add ubuntu/bionic64
vagrant up
vagrant ssh
cd synched_folder
python3 -c 'import shutil; shutil.rmtree("1a")'
*** Error message ***
rm -r 1a
*** Works fine ***

----------
components: Library (Lib)
files: Vagrantfile
messages: 359961
nosy: PeterFS
priority: normal
severity: normal
status: open
title: shutil.rmtree using vagrant synched folder fails
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48838/Vagrantfile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39327>
_______________________________________

From report at bugs.python.org  Tue Jan 14 04:53:32 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 14 Jan 2020 09:53:32 +0000
Subject: [issue39207] concurrent.futures.ProcessPoolExecutor does not properly
 reap jobs and spawns too many workers
In-Reply-To: <1578087844.56.0.81762061225.issue39207@roundup.psfhosted.org>
Message-ID: <1578995612.85.0.210669472227.issue39207@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

It would certainly be better to start the worker processes on demand. It  probably also requires careful thought about how to detect that more workers are required.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39207>
_______________________________________

From report at bugs.python.org  Tue Jan 14 05:13:07 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 14 Jan 2020 10:13:07 +0000
Subject: [issue39156] Break up COMPARE_OP into logically distinct operations.
In-Reply-To: <1577648682.52.0.347690468964.issue39156@roundup.psfhosted.org>
Message-ID: <1578996787.7.0.438421876472.issue39156@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 9af0e47b1705457bb6b327c197f2ec5737a1d8f6 by Mark Shannon in branch 'master':
bpo-39156: Break up COMPARE_OP into four logically distinct opcodes. (GH-17754)
https://github.com/python/cpython/commit/9af0e47b1705457bb6b327c197f2ec5737a1d8f6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39156>
_______________________________________

From report at bugs.python.org  Tue Jan 14 05:13:33 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 14 Jan 2020 10:13:33 +0000
Subject: [issue39156] Break up COMPARE_OP into logically distinct operations.
In-Reply-To: <1577648682.52.0.347690468964.issue39156@roundup.psfhosted.org>
Message-ID: <1578996813.82.0.419836484771.issue39156@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39156>
_______________________________________

From report at bugs.python.org  Tue Jan 14 06:39:23 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Jan 2020 11:39:23 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1579001963.78.0.138181190035.issue39033@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9955f33cdbf27de270038dfbad37d15b160ecca2 by Miss Islington (bot) (Karthikeyan Singaravelan) in branch '3.8':
[3.8] bpo-39033: Fix NameError in zipimport during hash validation (GH-17588) (GH-17642)
https://github.com/python/cpython/commit/9955f33cdbf27de270038dfbad37d15b160ecca2


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Tue Jan 14 06:41:34 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 14 Jan 2020 11:41:34 +0000
Subject: [issue39033] zipimport raises NameError: name '_boostrap_external' is
 not defined
In-Reply-To: <1576189217.79.0.0424351023121.issue39033@roundup.psfhosted.org>
Message-ID: <1579002094.66.0.771954443145.issue39033@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Thank you, Mihail and Karthikeyan!

----------
nosy: +petr.viktorin
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39033>
_______________________________________

From report at bugs.python.org  Tue Jan 14 06:53:00 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 14 Jan 2020 11:53:00 +0000
Subject: [issue39328] Allow filename mismatch in local and central directories
 in zipfile.py
Message-ID: <1579002780.47.0.570956156071.issue39328@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

This is being opened from the report on GH3035.

During malware research I bumped int problem with my Python based file analyzer: miscreants are modifying ZIP file header parts so, that python based automated analysis tools are unable to process the contents but intended clients are able to open the files with end-user applications and extract the possibly malicious contents. Proposed patch makes it possible to process the ZIP files even if such conditions occur. Default behavior remains the same (raise BadZipFile exception).

----------
messages: 359966
nosy: cheryl.sabella, gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow filename mismatch in local and central directories in zipfile.py
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39328>
_______________________________________

From report at bugs.python.org  Tue Jan 14 06:58:39 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 14 Jan 2020 11:58:39 +0000
Subject: [issue39048] Change the lookup order of __aenter__ and __aexit__ for
 async with
In-Reply-To: <1576353517.6.0.763131039625.issue39048@roundup.psfhosted.org>
Message-ID: <1579003119.04.0.317561119499.issue39048@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 1d1b97ae643dd8b22d87785ed7bd2599c6c8dc8d by Nick Coghlan (G?ry Ogam) in branch 'master':
bpo-39048: Look up __aenter__ before __aexit__ in async with (GH-17609)
https://github.com/python/cpython/commit/1d1b97ae643dd8b22d87785ed7bd2599c6c8dc8d


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39048>
_______________________________________

From report at bugs.python.org  Tue Jan 14 06:59:46 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 14 Jan 2020 11:59:46 +0000
Subject: [issue39048] Change the lookup order of __aenter__ and __aexit__ for
 async with
In-Reply-To: <1576353517.6.0.763131039625.issue39048@roundup.psfhosted.org>
Message-ID: <1579003186.84.0.645350209594.issue39048@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: behavior -> enhancement
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39048>
_______________________________________

From report at bugs.python.org  Tue Jan 14 07:05:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 12:05:17 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1579003517.41.0.117954027006.issue39259@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Tue Jan 14 07:05:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 12:05:40 +0000
Subject: [issue39259] poplib.POP3/POP3_SSL should reject timeout = 0
 (non-blocking mode)
In-Reply-To: <1578495346.65.0.262866907098.issue39259@roundup.psfhosted.org>
Message-ID: <1579003540.63.0.189756462216.issue39259@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Dong-hee Na for all these nice changes!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39259>
_______________________________________

From report at bugs.python.org  Tue Jan 14 07:06:48 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Jan 2020 12:06:48 +0000
Subject: [issue39322] Add gc.is_finalized to check if an object has been
 finalised by the gc
In-Reply-To: <1578928628.66.0.851687765453.issue39322@roundup.psfhosted.org>
Message-ID: <1579003608.9.0.645142059144.issue39322@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset a2ec3f07f7f028ff6229d6be2a7cfbda1f4efaeb by Pablo Galindo in branch 'master':
bpo-39322: Add gc.is_finalized to check if an object has been finalised by the gc (GH-17989)
https://github.com/python/cpython/commit/a2ec3f07f7f028ff6229d6be2a7cfbda1f4efaeb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39322>
_______________________________________

From report at bugs.python.org  Tue Jan 14 07:07:15 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Jan 2020 12:07:15 +0000
Subject: [issue39322] Add gc.is_finalized to check if an object has been
 finalised by the gc
In-Reply-To: <1578928628.66.0.851687765453.issue39322@roundup.psfhosted.org>
Message-ID: <1579003635.65.0.0687784208107.issue39322@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39322>
_______________________________________

From report at bugs.python.org  Tue Jan 14 07:10:18 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Tue, 14 Jan 2020 12:10:18 +0000
Subject: [issue39048] Look up __aenter__ before __aexit__ in async with
In-Reply-To: <1576353517.6.0.763131039625.issue39048@roundup.psfhosted.org>
Message-ID: <1579003818.97.0.575560528197.issue39048@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
title: Change the lookup order of __aenter__ and __aexit__ for async with -> Look up __aenter__ before __aexit__ in async with

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39048>
_______________________________________

From report at bugs.python.org  Tue Jan 14 07:19:39 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Tue, 14 Jan 2020 12:19:39 +0000
Subject: [issue39037] Look up __enter__ before __exit__ in the with statement
 documentation
In-Reply-To: <1576250377.83.0.345840572176.issue39037@roundup.psfhosted.org>
Message-ID: <1579004379.86.0.276939534686.issue39037@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
title: Fix the trial order of the __exit__ and __enter__ methods in the with statement documentation -> Look up __enter__ before __exit__ in the with statement documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39037>
_______________________________________

From report at bugs.python.org  Tue Jan 14 07:21:10 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Tue, 14 Jan 2020 12:21:10 +0000
Subject: [issue39048] Look up __aenter__ before __aexit__ in the async with
 statement
In-Reply-To: <1576353517.6.0.763131039625.issue39048@roundup.psfhosted.org>
Message-ID: <1579004470.27.0.904460628652.issue39048@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
title: Look up __aenter__ before __aexit__ in async with -> Look up __aenter__ before __aexit__ in the async with statement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39048>
_______________________________________

From report at bugs.python.org  Tue Jan 14 07:34:30 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 14 Jan 2020 12:34:30 +0000
Subject: [issue37751] In codecs,
 function 'normalizestring' should convert both spaces and hyphens to
 underscores.
In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org>
Message-ID: <1579005270.45.0.141531320991.issue37751@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

The change is backwards incompatible and a backport would break things. See for example how it breaks latexcodec:

https://bugzilla.redhat.com/show_bug.cgi?id=1789613#c2

----------
nosy: +hroncok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37751>
_______________________________________

From report at bugs.python.org  Tue Jan 14 07:40:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 12:40:03 +0000
Subject: [issue37751] In codecs,
 function 'normalizestring' should convert both spaces and hyphens to
 underscores.
In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org>
Message-ID: <1579005602.99.0.26235176708.issue37751@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17401
pull_request: https://github.com/python/cpython/pull/17997

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37751>
_______________________________________

From report at bugs.python.org  Tue Jan 14 07:41:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 12:41:44 +0000
Subject: [issue37751] In codecs,
 function 'normalizestring' should convert both spaces and hyphens to
 underscores.
In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org>
Message-ID: <1579005704.85.0.667467739213.issue37751@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The change is backwards incompatible and a backport would break things. See for example how it breaks latexcodec:

I reopen the issue. I proposed PR 17997 to *document* the incompatible change in What's New in Python 3.8. IMO it's a deliberate change and it's correct.

I rely on Marc-Andre Lemburg who implemented codecs and encodings modules. He wrote: "Jordon is right. Conversion has to be to underscores, not hyphens.".

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37751>
_______________________________________

From report at bugs.python.org  Tue Jan 14 07:42:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 12:42:40 +0000
Subject: [issue37751] In codecs,
 function 'normalizestring' should convert both spaces and hyphens to
 underscores.
In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org>
Message-ID: <1579005760.88.0.779279465115.issue37751@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems quite easy to update latexcodec project to support Python 3.9. I proposed a solution there:
https://bugzilla.redhat.com/show_bug.cgi?id=1789613#c6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37751>
_______________________________________

From report at bugs.python.org  Tue Jan 14 08:07:34 2020
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 14 Jan 2020 13:07:34 +0000
Subject: [issue37751] In codecs,
 function 'normalizestring' should convert both spaces and hyphens to
 underscores.
In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org>
Message-ID: <1579007254.18.0.621698879754.issue37751@roundup.psfhosted.org>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Just to clarify: the change in the C implementation was the breaking change. The patch just restores the previous behavior: https://github.com/python/cpython/blob/master/Lib/encodings/__init__.py#L43

Please note that external codec packages should not rely on the semantics of the Python stdlib encodings package's search function. They should really register their own search function: https://docs.python.org/3.9/library/codecs.html#codecs.register

It's good practice to always only use ASCII lower case chars and the underscore for codec names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37751>
_______________________________________

From report at bugs.python.org  Tue Jan 14 08:11:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 13:11:13 +0000
Subject: [issue37751] In codecs,
 function 'normalizestring' should convert both spaces and hyphens to
 underscores.
In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org>
Message-ID: <1579007473.74.0.433251365058.issue37751@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Please note that external codec packages should not rely on the semantics of the Python stdlib encodings package's search function.

latexcodec does register a search function.

> It's good practice to always only use ASCII lower case chars and the underscore for codec names.

latexcodec uses encoding names like "latex+ascii" and their search function used "+" as a separator.

Don't worry, I just fixed latexcodec, my fix is already merged upstream! I simply changed the search function to split on "_" if the name contains "_".

* https://github.com/mcmtroffaes/latexcodec/commit/a30ae2cf061d7369b1aaa8179ddd1b486974fdad
* https://github.com/mcmtroffaes/latexcodec/pull/76
* https://github.com/mcmtroffaes/latexcodec/issues/75

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37751>
_______________________________________

From report at bugs.python.org  Tue Jan 14 08:13:51 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Jan 2020 13:13:51 +0000
Subject: [issue39329] smtplib.LMTP needs timeout parameter
Message-ID: <1579007631.6.0.089521926624.issue39329@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

see: https://github.com/python/cpython/pull/17958#issuecomment-573390867

I've noticed that LMTP does not support the timeout parameter.
See: https://docs.python.org/3.9/library/smtplib.html#smtplib.LMTP

However, LMTP also able to use the socket which is created from SMTP.
IMHO LMTP needs to support the timeout parameter.

----------
assignee: corona10
components: Library (Lib)
messages: 359975
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: smtplib.LMTP needs timeout parameter
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39329>
_______________________________________

From report at bugs.python.org  Tue Jan 14 08:19:02 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Jan 2020 13:19:02 +0000
Subject: [issue39329] smtplib.LMTP needs timeout parameter
In-Reply-To: <1579007631.6.0.089521926624.issue39329@roundup.psfhosted.org>
Message-ID: <1579007942.44.0.705034164763.issue39329@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17402
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/17998

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39329>
_______________________________________

From report at bugs.python.org  Tue Jan 14 08:58:17 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Jan 2020 13:58:17 +0000
Subject: [issue39329] smtplib.LMTP needs timeout parameter
In-Reply-To: <1579007631.6.0.089521926624.issue39329@roundup.psfhosted.org>
Message-ID: <1579010297.98.0.777467494597.issue39329@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17403
pull_request: https://github.com/python/cpython/pull/17999

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39329>
_______________________________________

From report at bugs.python.org  Tue Jan 14 09:41:26 2020
From: report at bugs.python.org (Reece Dunham)
Date: Tue, 14 Jan 2020 14:41:26 +0000
Subject: [issue39330] Way to build without IDLE
Message-ID: <1579012886.09.0.695559726455.issue39330@roundup.psfhosted.org>


New submission from Reece Dunham <me at rdil.rocks>:

It would just be better in my opinion if there was a way to build without IDLE, for people that are building from source and don't want it.

This doesn't have to be implemented, it is just something I think would make the build system a bit better.

----------
components: Build
messages: 359976
nosy: rdil
priority: normal
severity: normal
status: open
title: Way to build without IDLE
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39330>
_______________________________________

From report at bugs.python.org  Tue Jan 14 10:04:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 15:04:19 +0000
Subject: [issue38530] Offer suggestions on AttributeError
In-Reply-To: <1571511451.65.0.74942926189.issue38530@roundup.psfhosted.org>
Message-ID: <1579014259.01.0.0392549011248.issue38530@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Related issue: PEP 534 -- Improved Errors for Missing Standard Library Modules
https://www.python.org/dev/peps/pep-0534/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38530>
_______________________________________

From report at bugs.python.org  Tue Jan 14 10:05:31 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 14 Jan 2020 15:05:31 +0000
Subject: [issue39330] Way to build without IDLE
In-Reply-To: <1579012886.09.0.695559726455.issue39330@roundup.psfhosted.org>
Message-ID: <1579014331.01.0.736346133883.issue39330@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +taleinat, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39330>
_______________________________________

From report at bugs.python.org  Tue Jan 14 10:47:38 2020
From: report at bugs.python.org (Guy Galun)
Date: Tue, 14 Jan 2020 15:47:38 +0000
Subject: [issue39331] 2to3 mishandles indented imports
Message-ID: <1579016858.37.0.175118756285.issue39331@roundup.psfhosted.org>


New submission from Guy Galun <galun.guy at gmail.com>:

When encountering an import that should be removed in Python 3 (e.g. "from itertools import izip"), 2to3 changes it a blank line, which may cause a runtime error if that import was indented:

error: module importing failed: expected an indented block (ptypes.py, line 10)
  File "temp.py", line 1, in <module>
  File "./lldbmacros/xnu.py", line 771, in <module>
    from memory import *
  File "./lldbmacros/memory.py", line 11, in <module>
    import macho
  File "./lldbmacros/macho.py", line 3, in <module>
    from macholib import MachO as macho
  File "./lldbmacros/macholib/MachO.py", line 10, in <module>
    from .mach_o import MH_FILETYPE_SHORTNAMES, LC_DYSYMTAB, LC_SYMTAB
  File "./lldbmacros/macholib/mach_o.py", line 16, in <module>
    from macholib.ptypes import p_uint32, p_uint64, Structure, p_long, pypackable

Relevant section before 2to3:

try:
    from itertools import izip, imap
except ImportError:
    izip, imap = zip, map
from itertools import chain, starmap

And after 2to3:

try:
    
except ImportError:
    izip, imap = zip, map
from itertools import chain, starmap


* Side note:
This specific case may only be problematic with scripts that are partially aware of Python 3, otherwise they wouldn't try-catch that import.

* Proposed solution:
In case of that kind of import being the single line of an indented block, change it to "pass" instead of a blank line.

----------
components: 2to3 (2.x to 3.x conversion tool)
files: ptypes.py
messages: 359978
nosy: galun.guy
priority: normal
severity: normal
status: open
title: 2to3 mishandles indented imports
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file48839/ptypes.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39331>
_______________________________________

From report at bugs.python.org  Tue Jan 14 11:22:34 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 14 Jan 2020 16:22:34 +0000
Subject: [issue39330] Way to build without IDLE
In-Reply-To: <1579012886.09.0.695559726455.issue39330@roundup.psfhosted.org>
Message-ID: <1579018954.55.0.870842095119.issue39330@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I'm not sure what you mean here.  IDLE is a pure-Python application, though it does depend on the optional tkinter package.  If you're on a UNIX platform and Tcl/Tk headers and libraries can't be found, _tkinter won't be built and you won't be able to run IDLE; on Windows if you pass the --no-tkinter (or -E) flag to PCbuild/build.bat, _tkinter won't be built and you won't be able to run IDLE.  In neither case is it an error to not have _tkinter (unless you try to import it).

There is no "building" of IDLE itself, and thus no way to not build it :)

----------
nosy: +zach.ware
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39330>
_______________________________________

From report at bugs.python.org  Tue Jan 14 11:51:48 2020
From: report at bugs.python.org (Reece Dunham)
Date: Tue, 14 Jan 2020 16:51:48 +0000
Subject: [issue39330] Way to build without IDLE
In-Reply-To: <1579012886.09.0.695559726455.issue39330@roundup.psfhosted.org>
Message-ID: <1579020708.19.0.416443239293.issue39330@roundup.psfhosted.org>


Reece Dunham <me at rdil.rocks> added the comment:

Okay, closing it then. Thanks for the info.

----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39330>
_______________________________________

From report at bugs.python.org  Tue Jan 14 11:58:51 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 14 Jan 2020 16:58:51 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1579021131.02.0.566163233181.issue39318@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I afraid that removing a file while the file descriptor is open 
> may not work on Windows. Seems this case is not well tested.

os.remove will succeed on a file that's opened with O_TEMPORARY, which shares delete access (i.e. FILE_SHARE_DELETE).

With classic Windows delete semantics, deleting a file sets the delete disposition on the filesystem's underlying file/link control block (FCB/LCB). The filesystem doesn't unlink the file from the directory until all File object references have been finalized. (A File handle refers to a kernel File object, which refers to an FCB/LCB in a filesystem. An FCB/LCB can be referenced by multiple File objects, such as from multiple CreateFileW calls, and a File object can be referenced by multiple handles, such as via inheritance or DuplicateHandle.) The deleted file remains accessible to existing File objects, and a File object with delete access can even be used to clear the delete disposition (i.e. undelete the file) via SetFileInformationByHandle: FileDispositionInfo. The file remains linked and visible in the parent directory, but no new access is allowed while its delete disposition is set. The parent directory cannot itself be deleted until the file is unlinked.

In Windows 10 1903, DeleteFileW has also been updated to use POSIX semantics if the filesystem supports it, which includes NTFS on the system drive, where temp files are usually created. With POSIX semantics, the file is unlinked as soon as DeleteFileW closes its File handle. All existing File objects can continue to access the file even though it's no longer linked in the directory. This includes being able to call GetFinalPathNameByHandleW, which, at least for NTFS, will show that the file has been moved to the special system directory "\$Extend\$Deleted" and renamed according to its file ID. As is usual for a deleted file, no new access is allowed, i.e. we cannot reopen a file in the "$Deleted" directory. Another change with POSIX semantics is that the delete is final. Existing File objects that have delete access are not allowed to clear the delete disposition (i.e. undelete the file).

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Tue Jan 14 12:13:17 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 14 Jan 2020 17:13:17 +0000
Subject: [issue39312] Expose placeholder reparse points in Windows
In-Reply-To: <1578839260.17.0.288692192504.issue39312@roundup.psfhosted.org>
Message-ID: <1579021997.88.0.461266165352.issue39312@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Given the minimum version requirement, I'd rather this support go into a third-party library. (Seems like a great candidate for a context manager, too.)

Recalling our debates about symlinks, I'd have to say that nothing about placeholder files qualifies them as links, regardless of whether Powershell puts "l" in the attributes summary :)

The ecosystem could really do with a Windows-aware filesystem library for this kind of support (and I might already be working on one occasionally, pitching it as a MSFT-supported package, which is why it's not public yet).

I'd rather keep the standard library as lowest common denominator for system interactions, particularly for behaviour like this that is either automatic+surprising or manual+platform-specific and insufficiently compelling (os.add_dll_directory being an example of something that was sufficiently compelling).

So I'm going to mark this as rejected, and steal the idea for my own library :D

----------
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39312>
_______________________________________

From report at bugs.python.org  Tue Jan 14 12:13:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Jan 2020 17:13:22 +0000
Subject: [issue39322] Add gc.is_finalized to check if an object has been
 finalised by the gc
In-Reply-To: <1578928628.66.0.851687765453.issue39322@roundup.psfhosted.org>
Message-ID: <1579022002.27.0.127118781482.issue39322@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +17404
pull_request: https://github.com/python/cpython/pull/18000

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39322>
_______________________________________

From report at bugs.python.org  Tue Jan 14 12:38:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 14 Jan 2020 17:38:22 +0000
Subject: [issue39322] Add gc.is_finalized to check if an object has been
 finalised by the gc
In-Reply-To: <1578928628.66.0.851687765453.issue39322@roundup.psfhosted.org>
Message-ID: <1579023502.69.0.597433806752.issue39322@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset b6791375b2ff86ea07f068fb53d9575c337eaa5b by Pablo Galindo in branch 'master':
bpo-39322: Add gc.is_finalized to the gc module docstring (GH-18000)
https://github.com/python/cpython/commit/b6791375b2ff86ea07f068fb53d9575c337eaa5b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39322>
_______________________________________

From report at bugs.python.org  Tue Jan 14 12:57:08 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 14 Jan 2020 17:57:08 +0000
Subject: [issue38361] syslog: Default "ident" in syslog.openlog() shouldn't
 contain slash
In-Reply-To: <1570102738.99.0.163183464343.issue38361@roundup.psfhosted.org>
Message-ID: <1579024628.44.0.225304292968.issue38361@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f04750bb7af45cb6efab8d92d1ff063f0bf2833d by Miss Islington (bot) (V?clav Barto?) in branch 'master':
bpo-38361: syslog: fixed making default "ident" from sys.argv[0] (GH-16557)
https://github.com/python/cpython/commit/f04750bb7af45cb6efab8d92d1ff063f0bf2833d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38361>
_______________________________________

From report at bugs.python.org  Tue Jan 14 13:08:32 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 14 Jan 2020 18:08:32 +0000
Subject: [issue39312] Expose placeholder reparse points in Windows
In-Reply-To: <1578839260.17.0.288692192504.issue39312@roundup.psfhosted.org>
Message-ID: <1579025312.43.0.0355835478408.issue39312@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Okay, a well-known third-party library will work if a script/application really needs this information. I just wanted to bring it up for consideration because I saw an issue for cross-platform PowerShell 6 [1] where it was decided to disable placeholder disguising, but that particular decision was motivated by the need to remain compatible with Windows PowerShell 5.

[1] https://github.com/PowerShell/PowerShell/pull/8745

> Recalling our debates about symlinks, I'd have to say that nothing 
> about placeholder files qualifies them as links, regardless of 
> whether Powershell puts "l" in the attributes summary :)

Certainly. A link (broadly speaking, including Unix-style symlinks and mount points) has to be a name surrogate. These OneDrive reparse points do not have the [N]ame surrogate bit set. It's not even allowed to be set because they have the [D]irectory bit set, which allows the directory entry in the filesystem to contain files. This is explained in km\ntifs.h:


    // The reparse tags are a ULONG. The 32 bits are laid out as follows:
    //
    //   3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
    //   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
    //  +-+-+-+-+-----------------------+-------------------------------+
    //  |M|R|N|D|     Reserved bits     |       Reparse Tag Value       |
    //  +-+-+-+-+-----------------------+-------------------------------+
    //
    // M is the Microsoft bit. When set to 1, it denotes a tag owned by Microsoft.
    //   All ISVs must use a tag with a 0 in this position.
    //   Note: If a Microsoft tag is used by non-Microsoft software, the
    //   behavior is not defined.
    //
    // R is reserved.  Must be zero for non-Microsoft tags.
    //
    // N is name surrogate. When set to 1, the file represents another named
    //   entity in the system.
    //
    // D is the directory bit. When set to 1, indicates that any directory
    //   with this reparse tag can have children. Has no special meaning when used
    //   on a non-directory file. Not compatible with the name surrogate bit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39312>
_______________________________________

From report at bugs.python.org  Tue Jan 14 13:25:50 2020
From: report at bugs.python.org (Jason Culligan)
Date: Tue, 14 Jan 2020 18:25:50 +0000
Subject: [issue39332] Python 3.6 compiler protections from Ubuntu distros
Message-ID: <1579026350.83.0.0617094618953.issue39332@roundup.psfhosted.org>


New submission from Jason Culligan <jason.culligan at intel.com>:

The python3.6 binary supplied in Ubuntu distros is not compiled with Position Independent Code (PIE) protection enabled.  Python2 does.  Is this not seen as a problem?

Example 1:
(checksec)
============

FILE:	/usr/bin/python2
RELRO:	Full RELRO
STACK CANARY:	Canary found
NX:	NX enabled
PIE:	PIE enabled <<<
RPATH:	No RPATH
RUNPATH:	No RUNPATH
Symbols:	No Symbols
FORTIFY:	Yes
Fortified:	14
Fortifiable:	32


FILE:	/usr/bin/python3.6
RELRO:	Partial RELRO <<< ISSUE >>>
STACK CANARY:	Canary found
NX:	NX enabled
PIE:	No PIE <<< ISSUE >>>
RPATH:	No RPATH
RUNPATH:	No RUNPATH
Symbols:	No Symbols
FORTIFY:	Yes
Fortified:	18
Fortifiable:	42


Example 2:
============

$ hardening-check /usr/bin/python2
/usr/bin/python2:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: yes

$ hardening-check /usr/bin/python3.6
/usr/bin/python3.6:
 Position Independent Executable: no, normal executable!
 Stack protected: yes
 Fortify Source functions: yes (some protected functions found)
 Read-only relocations: yes
 Immediate binding: no, not found!

----------
components: Build
messages: 359986
nosy: hpawdjit
priority: normal
severity: normal
status: open
title: Python 3.6 compiler protections from Ubuntu distros
type: security
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39332>
_______________________________________

From report at bugs.python.org  Tue Jan 14 13:29:23 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 14 Jan 2020 18:29:23 +0000
Subject: [issue39332] Python 3.6 compiler protections from Ubuntu distros
In-Reply-To: <1579026350.83.0.0617094618953.issue39332@roundup.psfhosted.org>
Message-ID: <1579026563.27.0.104537079389.issue39332@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

You should take it up on the Ubuntu issue tracker.

----------
nosy: +benjamin.peterson
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39332>
_______________________________________

From report at bugs.python.org  Tue Jan 14 14:58:28 2020
From: report at bugs.python.org (Tony)
Date: Tue, 14 Jan 2020 19:58:28 +0000
Subject: [issue39296] Windows register keys
In-Reply-To: <1578941352.02.0.217666004062.issue39296@roundup.psfhosted.org>
Message-ID: <5e1e1d61.1c69fb81.814dd.42b5@mx.google.com>


Tony <factoryx.code at gmail.com> added the comment:

Hi Steve,

Thank you for this. 
I know about the working of WOW64 and the redirection to the (HKEY_LOCAL_MACHINE) ..\Wow6432Node, that is explained on md.docs.
The HKEY_CURRENT_USER redirection is not well explained, and so it appears I?m not the only one (Google) who was confused about this behavior.
So, again, many thanks for your explanation!

Tony Kalf.

Van: Steve Dower
Verzonden: maandag 13 januari 2020 19:49
Aan: factoryx.code at gmail.com
Onderwerp: [issue39296] Windows register keys

Steve Dower <steve.dower at python.org> added the comment:

You should read the version number from the Version or SysVersion values, rather than from the tag.

Having -32 in the key name is a compatibility requirement. Without it, if you installed 32-bit and 64-bit versions for the current user (which is now the default), they would overwrite each other.

The Wow6432Node key is due to Windows, not Python. We don't decide the name or when it is used, and Windows determined that HKEY_CURRENT_USER is not subject to registry redirection. That's why you don't see it there.

Hope that helps clarify what's going on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39296>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39296>
_______________________________________

From report at bugs.python.org  Tue Jan 14 15:29:56 2020
From: report at bugs.python.org (Luciana)
Date: Tue, 14 Jan 2020 20:29:56 +0000
Subject: [issue39305] Merge nntplib._NNTPBase and nntplib.NNTP
In-Reply-To: <1578757948.77.0.383613154988.issue39305@roundup.psfhosted.org>
Message-ID: <1579033796.01.0.209301420812.issue39305@roundup.psfhosted.org>


Luciana <lucianadacostamarques at gmail.com> added the comment:

Hey, I'm taking a look into this!

----------
nosy: +lucianamarques

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39305>
_______________________________________

From report at bugs.python.org  Tue Jan 14 15:32:51 2020
From: report at bugs.python.org (Luciana)
Date: Tue, 14 Jan 2020 20:32:51 +0000
Subject: [issue39206] Modulefinder does not consider source file encoding
In-Reply-To: <1578087235.53.0.0551529290674.issue39206@roundup.psfhosted.org>
Message-ID: <1579033971.1.0.708036817525.issue39206@roundup.psfhosted.org>


Luciana <lucianadacostamarques at gmail.com> added the comment:

Hi there, can somebody who is a core dev please review my PR? Thanks :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39206>
_______________________________________

From report at bugs.python.org  Tue Jan 14 15:36:54 2020
From: report at bugs.python.org (Jack Orenstein)
Date: Tue, 14 Jan 2020 20:36:54 +0000
Subject: [issue39333] argparse should offer an alternative to SystemExit in
 case a parse fails
Message-ID: <1579034214.28.0.98730978231.issue39333@roundup.psfhosted.org>


New submission from Jack Orenstein <jao at geophile.com>:

If parse_args fails, SystemExit is raised, carrying an exit code of 2, and the help message is printed. For an embedded usage of argparse, this behavior is undesirable.

I am writing an interactive console application, using argparse to parse input. When a parse fails, I would like to print an error message and continue, not terminate the program. Currently, I need to catch SystemExit to be able to do this, which has obvious problems, (e.g., what if something other that argparse is causing the exit?)

I'd like to see some way to specify alternative behavior, e.g. raise an exception of a given type.

----------
components: Library (Lib)
messages: 359991
nosy: geophile
priority: normal
severity: normal
status: open
title: argparse should offer an alternative to SystemExit in case a parse fails
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39333>
_______________________________________

From report at bugs.python.org  Tue Jan 14 15:44:22 2020
From: report at bugs.python.org (Joy)
Date: Tue, 14 Jan 2020 20:44:22 +0000
Subject: [issue38921] Max Recursion Depth Reached in Logging Library
In-Reply-To: <1574793583.29.0.769726111814.issue38921@roundup.psfhosted.org>
Message-ID: <1579034662.16.0.284032291862.issue38921@roundup.psfhosted.org>


Joy <joy.bushnell at gmail.com> added the comment:

This script should produce the following error:

Traceback (most recent call last):
  File "logging_test_script.py", line 70, in <module>
    testobj.main()
  File "logging_test_script.py", line 62, in main
    Logger.main_logger.info('Adding a line into {}'.format(source))
  File "/usr/lib/python3.7/logging/__init__.py", line 1378, in info
    self._log(INFO, msg, args, **kwargs)
  File "/usr/lib/python3.7/logging/__init__.py", line 1514, in _log
    self.handle(record)
  File "/usr/lib/python3.7/logging/__init__.py", line 1524, in handle
    self.callHandlers(record)
  File "/usr/lib/python3.7/logging/__init__.py", line 1586, in callHandlers
    hdlr.handle(record)
  File "/usr/lib/python3.7/logging/__init__.py", line 894, in handle
    self.emit(record)
  File "/usr/lib/python3.7/logging/__init__.py", line 1127, in emit
    StreamHandler.emit(self, record)
  File "/usr/lib/python3.7/logging/__init__.py", line 1025, in emit
    msg = self.format(record)
  File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
    return fmt.format(record)
  File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
    return fmt.format(record)
  File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
    return fmt.format(record)
  [Previous line repeated 984 more times]
  File "/usr/lib/python3.7/logging/__init__.py", line 609, in format
    if self.usesTime():
  File "/usr/lib/python3.7/logging/__init__.py", line 577, in usesTime
    return self._style.usesTime()
  File "/usr/lib/python3.7/logging/__init__.py", line 419, in usesTime
    return self._fmt.find(self.asctime_search) >= 0
RecursionError: maximum recursion depth exceeded while calling a Python object

----------
Added file: https://bugs.python.org/file48840/logging_test_script.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38921>
_______________________________________

From report at bugs.python.org  Tue Jan 14 15:45:32 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 14 Jan 2020 20:45:32 +0000
Subject: [issue39333] argparse should offer an alternative to SystemExit in
 case a parse fails
In-Reply-To: <1579034214.28.0.98730978231.issue39333@roundup.psfhosted.org>
Message-ID: <1579034732.78.0.539591842166.issue39333@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39333>
_______________________________________

From report at bugs.python.org  Tue Jan 14 15:49:38 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 14 Jan 2020 20:49:38 +0000
Subject: [issue38901] [venv] Add a CLI flag to venv to use the pwd basename as
 the prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1579034978.25.0.324921607201.issue38901@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 7d6378051feeadf45b4ce45b4b406b65df255648 by Vinay Sajip in branch 'master':
bpo-38901: Allow setting a venv's prompt to the basename of the current directory. (GH-17946)
https://github.com/python/cpython/commit/7d6378051feeadf45b4ce45b4b406b65df255648


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Tue Jan 14 15:52:18 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 14 Jan 2020 20:52:18 +0000
Subject: [issue39333] argparse should offer an alternative to SystemExit in
 case a parse fails
In-Reply-To: <1579034214.28.0.98730978231.issue39333@roundup.psfhosted.org>
Message-ID: <1579035138.52.0.385451013731.issue39333@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Does overriding exit help here?

https://docs.python.org/3.8/library/argparse.html#argparse.ArgumentParser.exit

----------
nosy: +paul.j3, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39333>
_______________________________________

From report at bugs.python.org  Tue Jan 14 15:53:32 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 14 Jan 2020 20:53:32 +0000
Subject: [issue39333] argparse should offer an alternative to SystemExit in
 case a parse fails
In-Reply-To: <1579034214.28.0.98730978231.issue39333@roundup.psfhosted.org>
Message-ID: <1579035212.2.0.765736294741.issue39333@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Maybe argparse could raise an exception derived from SystemExit, then you could catch that.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39333>
_______________________________________

From report at bugs.python.org  Tue Jan 14 15:54:30 2020
From: report at bugs.python.org (Julien Palard)
Date: Tue, 14 Jan 2020 20:54:30 +0000
Subject: [issue39334] python specific index directives in our doc has been
 deprecated 10 years ago
Message-ID: <1579035270.07.0.838861663002.issue39334@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

see: https://github.com/sphinx-doc/sphinx/pull/6970

----------
assignee: mdk
components: Documentation
messages: 359996
nosy: mdk
priority: normal
severity: normal
status: open
title: python specific index directives in our doc has been deprecated 10 years ago

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39334>
_______________________________________

From report at bugs.python.org  Tue Jan 14 15:54:56 2020
From: report at bugs.python.org (Julien Palard)
Date: Tue, 14 Jan 2020 20:54:56 +0000
Subject: [issue39334] python specific index directives in our doc has been
 deprecated 10 years ago
In-Reply-To: <1579035270.07.0.838861663002.issue39334@roundup.psfhosted.org>
Message-ID: <1579035296.11.0.970645312516.issue39334@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
keywords: +patch
pull_requests: +17405
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18004

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39334>
_______________________________________

From report at bugs.python.org  Tue Jan 14 15:59:52 2020
From: report at bugs.python.org (Jack Orenstein)
Date: Tue, 14 Jan 2020 20:59:52 +0000
Subject: [issue39333] argparse should offer an alternative to SystemExit in
 case a parse fails
In-Reply-To: <1579034214.28.0.98730978231.issue39333@roundup.psfhosted.org>
Message-ID: <1579035592.35.0.247849461423.issue39333@roundup.psfhosted.org>


Jack Orenstein <jao at geophile.com> added the comment:

Yes! I didn't know about that method, thank you.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39333>
_______________________________________

From report at bugs.python.org  Tue Jan 14 16:00:11 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 14 Jan 2020 21:00:11 +0000
Subject: [issue39295] usage of bitfields in ctypes structures changed between
 3.7.5 and 3.7.6
In-Reply-To: <1578694567.2.0.498689301236.issue39295@roundup.psfhosted.org>
Message-ID: <1579035611.51.0.124590726212.issue39295@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> With Python 3.7.6 this raises an exception at the ctypes.CFUNCTYPE() 
> call with
> ...
> TypeError: item 1 in _argtypes_ passes a struct/union with a bitfield
> by value, which is unsupported.

I cannot reproduce the problem as stated in 3.7.6 in Windows. The TypeError only occurs if I use the struct type directly in argtypes, not a pointer to the struct type. For example:

    >>> class A(ctypes.Structure):
    ...     _fields_ = (('x', ctypes.c_uint, 1),)

    >>> class P_A(ctypes._Pointer):
    ...     _type_ = A
    ...

allowed:

    >>> class FP_P_A(ctypes._CFuncPtr):
    ...     _flags_ = ctypes._FUNCFLAG_CDECL
    ...     _argtypes_ = (P_A,)

disallowed:

    >>> class FP_A(ctypes._CFuncPtr):
    ...     _flags_ = ctypes._FUNCFLAG_CDECL
    ...     _argtypes_ = (A,)
    ...
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: item 1 in _argtypes_ passes a struct/union with a bitfield by value, which is unsupported.

This seems rights to me. There is no problem passing a pointer as a function parameter.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39295>
_______________________________________

From report at bugs.python.org  Tue Jan 14 16:08:15 2020
From: report at bugs.python.org (Hrvoje Abraham)
Date: Tue, 14 Jan 2020 21:08:15 +0000
Subject: [issue39335] round Decimal edge case
Message-ID: <1579036095.34.0.13379826917.issue39335@roundup.psfhosted.org>


New submission from Hrvoje Abraham <ahrvoje at gmail.com>:

>>> from decimal import Decimal
>>> round(Decimal('-123.499999999999999999999999999999999999999999'))
-124.0

I would expect -123.0, even considering Py2 rounding convention details (away from zero), Decimal rounding convention (default rounding=ROUND_HALF_EVEN), floating point specifics...

Works as expected in Py3. Both Py2 and Py3 use same default Decimal rounding=ROUND_HALF_EVEN.

Could be I'm missing some detail...

----------
components: Library (Lib)
messages: 359999
nosy: ahrvoje
priority: normal
severity: normal
status: open
title: round Decimal edge case
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39335>
_______________________________________

From report at bugs.python.org  Tue Jan 14 16:33:31 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 14 Jan 2020 21:33:31 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
Message-ID: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>


New submission from Dino Viehland <dinoviehland at gmail.com>:

I'm trying to create a custom module type for a custom loader where the returned modules are immutable.  But I'm running into an issue where the immutable module type can't be used as a module for a package.  That's because the import machinery calls setattr to set the module as an attribute on it's parent in _boostrap.py

        # Set the module as an attribute on its parent.
        parent_module = sys.modules[parent]
        setattr(parent_module, name.rpartition('.')[2], module)

I'd be okay if for these immutable module types they simply didn't have their children packages published on them.

A simple simulation of this is a package which replaces its self with an object which doesn't support adding arbitrary attributes:

x/__init__.py:
import sys

class MyMod(object):
    __slots__ = ['__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__']
    def __init__(self):
        for attr in self.__slots__:
            setattr(self, attr, globals()[attr])


sys.modules['x'] = MyMod()

x/y.py:
# Empty file

>>> from x import y
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<frozen importlib._bootstrap>", line 983, in _find_and_load
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load_unlocked
AttributeError: 'MyMod' object has no attribute 'y'

There's a few different options I could see on how this could be supported:
    1) Simply handle the attribute error and allow things to continue
    2) Add ability for the modules loader to perform the set, and fallback to setattr if one isn't available.  Such as:
         getattr(parent_module, 'add_child_module', setattr)(parent_module, name.rpartition('.')[2], module)
    3) Add the ability for the module type to handle the setattr:
         getattr(type(parent_module), 'add_child_module', fallback)(parent_module, 
, name.rpartition('.')[2], module)

----------
assignee: dino.viehland
components: Interpreter Core
messages: 360000
nosy: dino.viehland
priority: normal
severity: normal
stage: needs patch
status: open
title: Immutable module type can't be used as package in custom loader
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Tue Jan 14 16:40:20 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 14 Jan 2020 21:40:20 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1579038020.53.0.53706894001.issue39336@roundup.psfhosted.org>


Change by Dino Viehland <dinoviehland at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Tue Jan 14 16:42:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 21:42:16 +0000
Subject: [issue39329] smtplib.LMTP needs timeout parameter
In-Reply-To: <1579007631.6.0.089521926624.issue39329@roundup.psfhosted.org>
Message-ID: <1579038136.43.0.397366758866.issue39329@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 65a5ce247f177c4c52cfd104d9df0c2f3b1c91f0 by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-39329: Add timeout parameter for smtplib.LMTP constructor (GH-17998)
https://github.com/python/cpython/commit/65a5ce247f177c4c52cfd104d9df0c2f3b1c91f0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39329>
_______________________________________

From report at bugs.python.org  Tue Jan 14 16:42:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 21:42:46 +0000
Subject: [issue39329] smtplib.LMTP needs timeout parameter
In-Reply-To: <1579007631.6.0.089521926624.issue39329@roundup.psfhosted.org>
Message-ID: <1579038166.99.0.383576280562.issue39329@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

PR merged, thanks.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39329>
_______________________________________

From report at bugs.python.org  Tue Jan 14 16:54:37 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 14 Jan 2020 21:54:37 +0000
Subject: [issue38901] [venv] Add a CLI flag to venv to use the pwd basename as
 the prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1579038877.26.0.388938761367.issue38901@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Can this now be closed, Vinay?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Tue Jan 14 16:54:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 21:54:42 +0000
Subject: [issue39337] codecs.lookup() ignores non-ASCII characters,
 whereas encodings.normalize_encoding() copies them
Message-ID: <1579038882.16.0.589810918272.issue39337@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

bpo-37751 changed codecs.lookup() in a subtle way: non-ASCII characters are now ignored, whereas they were copied unmodified previously.

I would prefer that codecs.lookup() and encodings.normalize_encoding() behave the same. Either always ignore or always copy.

Moreover, it seems like there is no test on how the encoding names are normalized in codecs.register(). I recall that using codecs.register() in an unit test causes troubles since there is no API to unregister a search function. Maybe we should just add a private function for test in _testcapi.

Serhiy Storchaka wrote an example on my PR:
https://github.com/python/cpython/pull/17997/files

> There are other differences. For example, normalize_encoding("???-8") returns "???_8", but codecs.lookup normalizes it to "8".

> The comment in the sources is also not correct.

----------
components: Library (Lib)
messages: 360004
nosy: lemburg, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: codecs.lookup() ignores non-ASCII characters, whereas encodings.normalize_encoding() copies them
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39337>
_______________________________________

From report at bugs.python.org  Tue Jan 14 16:54:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 14 Jan 2020 21:54:58 +0000
Subject: [issue37751] In codecs,
 function 'normalizestring' should convert both spaces and hyphens to
 underscores.
In-Reply-To: <1564832053.37.0.298269063007.issue37751@roundup.psfhosted.org>
Message-ID: <1579038898.78.0.182242120529.issue37751@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-39337: codecs.lookup() ignores non-ASCII characters, whereas encodings.normalize_encoding() copies them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37751>
_______________________________________

From report at bugs.python.org  Tue Jan 14 17:16:53 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 14 Jan 2020 22:16:53 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1579040213.71.0.613879019712.issue39336@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

So I think this is way too marginal a use-case to expand the API to let loaders inject themselves into the semantics of it.

I assume going with option 1 but raising an ImportWarning would be too noisy for your use-case? If not I'm totally fine with that solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Tue Jan 14 17:23:01 2020
From: report at bugs.python.org (Y3Kv Bv)
Date: Tue, 14 Jan 2020 22:23:01 +0000
Subject: [issue39338] Data lost randomly from dictionary after creating the
 dictionary
Message-ID: <1579040581.36.0.0302070904511.issue39338@roundup.psfhosted.org>


New submission from Y3Kv Bv <yk3b.bw.ggxwkimobz at gmail.com>:

Windows 7 x64, Python 3.8.1

I've encountered a very weird issue where after creating a dictionary from a list the dictionary ends up being shorter/data is lost from it.
It's absolutely random when it loses, how many and which items are lost.

I've attached the example file with the code that always has a chance to trigger the issue for me.

I've managed to figure only this much that when "if useAmp" never triggers, data loss will never occur. I've added checkpoints to verify where the loss occurs and it's not caused by "if useAmp" block directly, data loss happens exactly after the dictionary is created.

----------
files: test.py
messages: 360007
nosy: Y3Kv Bv
priority: normal
severity: normal
status: open
title: Data lost randomly from dictionary after creating the dictionary
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48841/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39338>
_______________________________________

From report at bugs.python.org  Tue Jan 14 17:55:49 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 14 Jan 2020 22:55:49 +0000
Subject: [issue39338] Data lost randomly from dictionary after creating the
 dictionary
In-Reply-To: <1579040581.36.0.0302070904511.issue39338@roundup.psfhosted.org>
Message-ID: <1579042549.63.0.2010047465.issue39338@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I suspect your `useAmp` branch is not doing what you think it's doing: it's effectively replacing a random number of entries in your `crazyQuilt2` list with a duplicate entry (try `print`ing the list every time around the main loop to see what's happening to it).  When you later create a dict using the entries of the list as keys there are only so many unique keys, and thus the dict is not the same length as the list.

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39338>
_______________________________________

From report at bugs.python.org  Tue Jan 14 17:56:24 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 14 Jan 2020 22:56:24 +0000
Subject: [issue34922] hashlib segmentation fault
In-Reply-To: <1538916029.97.0.545547206417.issue34922@psf.upfronthosting.co.za>
Message-ID: <1579042584.74.0.255531687758.issue34922@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Since there has been no further discussion on this since the fixes were pushed over a year ago, I am declaring this issue resolved.  Thanks for everyone's help!

----------
assignee: ned.deily -> 
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34922>
_______________________________________

From report at bugs.python.org  Tue Jan 14 18:01:12 2020
From: report at bugs.python.org (Tim Peters)
Date: Tue, 14 Jan 2020 23:01:12 +0000
Subject: [issue39338] Data lost randomly from dictionary after creating the
 dictionary
In-Reply-To: <1579040581.36.0.0302070904511.issue39338@roundup.psfhosted.org>
Message-ID: <1579042872.09.0.341100384678.issue39338@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

What, exactly, in the output shows "the problem"?  When I run it, the `a == b` part is always True, while `len(x)` and `len(crazyQuilt2)` are always 30.  The other three (len(coordinates), len(x2), len(x3)) are always equal to each other, but are monotonically non-increasing across output lines.  For example, a typical block of output lines:

(True, 30, 30, 30, 30, 30)
(True, 30, 30, 30, 30, 30)
(True, 30, 30, 30, 30, 30)
(True, 30, 30, 30, 30, 30)
(True, 19, 30, 30, 19, 19)
(True, 19, 30, 30, 19, 19)
(True, 19, 30, 30, 19, 19)
(True, 12, 30, 30, 12, 12)
(True, 12, 30, 30, 12, 12)
(True, 12, 30, 30, 12, 12)

None of that surprises me.  Exactly what about it surprises you?  Or do you get different kinds of output (and, if so, exactly what?)?

Here's my guess:  you _intended_ these two lines:

          crazyQuilt2[coordinate2Index] = crazyQuilt2[index]
          crazyQuilt2[index] = crazyQuilt2[coordinate2Index]

to _swap_ the values at indices `index` and `coordinate2Index`.  But they don't.  They copy the value originally at `index` into the `coordinate2Index` position, and leave the value originally at `index` untouched.

As more copies randomly build up, anything that builds a set or dict out of the list naturally gets smaller.

----------
nosy: +tim.peters -zach.ware
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39338>
_______________________________________

From report at bugs.python.org  Tue Jan 14 18:02:31 2020
From: report at bugs.python.org (Tim Peters)
Date: Tue, 14 Jan 2020 23:02:31 +0000
Subject: [issue39338] Data lost randomly from dictionary after creating the
 dictionary
In-Reply-To: <1579040581.36.0.0302070904511.issue39338@roundup.psfhosted.org>
Message-ID: <1579042951.11.0.144695192071.issue39338@roundup.psfhosted.org>


Change by Tim Peters <tim at python.org>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39338>
_______________________________________

From report at bugs.python.org  Tue Jan 14 18:11:31 2020
From: report at bugs.python.org (Y3Kv Bv)
Date: Tue, 14 Jan 2020 23:11:31 +0000
Subject: [issue39338] Data lost randomly from dictionary after creating the
 dictionary
In-Reply-To: <1579040581.36.0.0302070904511.issue39338@roundup.psfhosted.org>
Message-ID: <1579043491.47.0.776303900349.issue39338@roundup.psfhosted.org>


Y3Kv Bv <yk3b.bw.ggxwkimobz at gmail.com> added the comment:

I'm a newbie at Python, also obviously not thinking hard enough over Python's mechanics. Shame on me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39338>
_______________________________________

From report at bugs.python.org  Tue Jan 14 18:32:13 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 14 Jan 2020 23:32:13 +0000
Subject: [issue39305] Merge nntplib._NNTPBase and nntplib.NNTP
In-Reply-To: <1578757948.77.0.383613154988.issue39305@roundup.psfhosted.org>
Message-ID: <1579044733.04.0.0534357722105.issue39305@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@lucianamarques

Good news, if you submit the patch.
Please ping me and @vstinner :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39305>
_______________________________________

From report at bugs.python.org  Tue Jan 14 18:40:54 2020
From: report at bugs.python.org (Matthew Newville)
Date: Tue, 14 Jan 2020 23:40:54 +0000
Subject: [issue39295] usage of bitfields in ctypes structures changed between
 3.7.5 and 3.7.6
In-Reply-To: <1578694567.2.0.498689301236.issue39295@roundup.psfhosted.org>
Message-ID: <1579045254.13.0.469822771246.issue39295@roundup.psfhosted.org>


Matthew Newville <matt.newville at gmail.com> added the comment:

@eryksun Sorry for the imprecision -- I was mixing what we do on Linux and Windows. A minimum verifiable example for Linux/MacOS would be

    import ctypes
    class bitstruct(ctypes.Structure):
        _fields_ = [('addr', ctypes.c_long),
                    ('rbit', ctypes.c_uint, 1),
                    ('wbit', ctypes.c_uint, 1)]

    def handler(args):
        print("handler: ", args.addr, args.rbit, args.wbit)

    callback = ctypes.CFUNCTYPE(None, bitstruct)(handler)

This works with 3.7.5 but raises a TypeError with 3.7.6.

For Windows (or, well, 64-bit Windows, the only kind we bother to support), we find that we have to wrap the function and use a POINTER to the struct, so what we really use is more like

    import os, functools
    def make_callback(args, func):
        """ make callback function"""
        @functools.wraps(func)
        def wrapped(arg, **kwargs):
            if hasattr(arg, 'contents'):
                return func(arg.contents, **kwargs)
            return func(arg, **kwargs)
        if os.name =='nt': # also check for 64-bit
            cb = ctypes.CFUNCTYPE(None, ctypes.POINTER(args))(wrapped)
        else:
            cb = ctypes.CFUNCTYPE(None, bitstruct)(handler)
        return cb

   callback = make_callback(bitstruct, handler)


> ...
> This seems rights to me. There is no problem passing a pointer 
> as a function parameter.

The problem here is that code that worked with 3.7.5 raises a TypeError with 3.7.6.

I don't know that the solution we came up with is actually the best approach.  I've asked for such guidance a few times now.  I don't know why using a pointer would be required for a structure containing a "u_int, 1", but not for other structures, but any guidance would be much appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39295>
_______________________________________

From report at bugs.python.org  Tue Jan 14 18:51:07 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 14 Jan 2020 23:51:07 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1579045867.84.0.811602580625.issue39336@roundup.psfhosted.org>


Change by Dino Viehland <dinoviehland at gmail.com>:


----------
keywords: +patch
pull_requests: +17406
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18006

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Tue Jan 14 18:55:02 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 14 Jan 2020 23:55:02 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1579046102.6.0.43371290484.issue39336@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

I think the warning shouldn't be too bad.  It looks like ImportWarnings are filtered by default already, and the extra overhead of raising a warning in this case probably is nothing compared to the actual work in loading the module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Tue Jan 14 18:57:53 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 14 Jan 2020 23:57:53 +0000
Subject: [issue38901] [venv] Add a CLI flag to venv to use the pwd basename as
 the prompt
In-Reply-To: <1574548114.45.0.822354865234.issue38901@roundup.psfhosted.org>
Message-ID: <1579046273.73.0.883414949497.issue38901@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38901>
_______________________________________

From report at bugs.python.org  Tue Jan 14 19:40:44 2020
From: report at bugs.python.org (Tim Peters)
Date: Wed, 15 Jan 2020 00:40:44 +0000
Subject: [issue39338] Data lost randomly from dictionary after creating the
 dictionary
In-Reply-To: <1579040581.36.0.0302070904511.issue39338@roundup.psfhosted.org>
Message-ID: <1579048844.65.0.53326658881.issue39338@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

No problem!  If you are trying to swap the values in two variables `x` and `y`, in most languages that's spelled:

    temp = x
    x = y
    y = temp

and that works in Python too.  But in Python it's more common to do it with a one-liner:

    x, y = y, x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39338>
_______________________________________

From report at bugs.python.org  Tue Jan 14 20:24:19 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 15 Jan 2020 01:24:19 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579051459.94.0.350624914779.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Am I seriously suggesting this for Python?  Sure.  It's fun to advance the practical state of the art :-)


I think this API looks very interesting! I have some questions before start implementing it to play a bit with it:

- I am slightly confused about what .prepare() should do. Why is this step necessary?

- Why we need the .done() method here? Why not instead make get_ready() simply a generator so you can just write

    for node in self.get_ready():

It seems that the .done() is very tight to use this API as a "task scheduler" but maybe I am doing something here in
my understanding of the API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Tue Jan 14 21:04:00 2020
From: report at bugs.python.org (Tim Peters)
Date: Wed, 15 Jan 2020 02:04:00 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579053840.4.0.695709367978.issue17005@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

> I am slightly confused about what .prepare() should do. Why
> is this step necessary?

To say "I'm done adding edges".  Any call to add() after prepare() should raise an exception.  Likewise, e.g., any call to get_ready() before prepare() should raise an exception.  In a bog-standard topsort implementation, saving for each node a sequence of successors and a count of predecessors, this is also the time to collect all the nodes that have no predecessors (the first batch returned by get_ready()).

Much the same could be done without prepare() by get_ready() making a special case out of the first time it's called.  That's more magical, though.  "I'm done adding edges" is utterly non-magical.

> - Why we need the .done() method here? Why not instead make get_ready()
> simply a generator so you can just write
>
>    for node in self.get_ready():

The point of done() is to enable maximum exploitation of parallelism.  As already sketched, if a user doesn't care about that, fine, a different method (like static_order()) can generate all the nodes in _some_ static topsort order, with no need for done().

But suppose a user does care about parallelism.  Consider graph

A -> B
A -> C
A -> D
B -> D

Output A B C D is a topsort, but useless unless the user is content to "do" one node at a time.

Instead get_ready() first returns [A] (or a tuple, or a generator, or a set ... something iterable).  A is handed out to worker processes/threads, but get_ready() will return an empty iterable until done(A) is called.  Indeed, if "doing" A fails, it's NOT the case that anything else can ever be started.

If/when "doing A" succeeds, then done(A) is called, and the next get_ready() returns [B, C].  Those can be done in parallel, but D can't be started until done(B) is called.  done(B) may or may not be called before done(C) is called - the topsort itself has no way to know in advance, nor _should_ it impose its own view of that.  Note that D does not depend on C, so there's no need to wait for _both_ in [B, C] to finish.  It's necessary and sufficient that B be marked done() for D to be ready to go.

> It seems that the .done() is very tight to use this API as a "task
> scheduler" but maybe I am doing something here in my understanding
> of the API.

done() says nothing about how the user "should" schedule work items, but instead allows get_ready() to return all the work items whose predecessors have been marked done() (but haven't already been passed out by get_ready()).  That's the maximum set of nodes that _can_ be worked on at the time.  The topsort class itself has no policy about how or when they "should" be worked on, get_ready() is just identifying all the possibilities that exist.  Which is impossible to know unless the class is also told which nodes it already passed out have finished - the purpose of done().

is_active() eventually returns False when all the nodes passed out by get_ready() have been marked done(), _and_ there are no more nodes ready to pass out.  At that point, there's a cycle in the input relations if and only if there's some node get_ready() never passed out.

In my prototype implementation, that's another thing prepare() does:  checks for a cycle, and raises CycleError if there is one.  The user can catch & ignore that if they like, and continue calling get_ready() and done() until no more progress can be made.  I think it's more likely, though, that the user would stare at the cycle attached to the CycleError instance, do whatever it takes to break the cycle, and start over again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Tue Jan 14 21:40:12 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 15 Jan 2020 02:40:12 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579056012.06.0.936232198108.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Fair enough, I will read this carefully again and try to sketch a prototype soon :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Tue Jan 14 21:56:47 2020
From: report at bugs.python.org (Tim Peters)
Date: Wed, 15 Jan 2020 02:56:47 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579057007.62.0.473489648329.issue17005@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I'll add ts.py, which was a work-in-progress that implements a minor variation of most everything I typed about.  If nothing else, its _find_cycle is useful as a non-recursive linear-time cycle finder (recursion is deadly here because recursive depth-first search can easily "blow the stack" on larger graphs).

There's also "if 1:"/"else:" blocks that set up parallel cases, using threads or processes, and two ways of managing the parallelism (the one I showed before, and a more elaborate one that puts an upper bound on how large the queues can grow - which is sometimes "a problem" for multiprocessing.queue).

----------
Added file: https://bugs.python.org/file48842/ts.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Tue Jan 14 22:01:41 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 15 Jan 2020 03:01:41 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579057301.97.0.953323321296.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Disregarding the API, what do you think about the approach of https://github.com/python/cpython/pull/11583 for the implementation? Under my benchmarks (check previous comments) it seems to perform very good with regards to memory and time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Tue Jan 14 22:12:42 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 15 Jan 2020 03:12:42 +0000
Subject: [issue39335] round Decimal edge case
In-Reply-To: <1579036095.34.0.13379826917.issue39335@roundup.psfhosted.org>
Message-ID: <1579057962.53.0.0811237706617.issue39335@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

On Python 2, round just converts the decimal to a float. So, this is a consequence of:

>>> float(Decimal('-123.499999999999999999999999999999999999999999'))
-123.5

----------
nosy: +benjamin.peterson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39335>
_______________________________________

From report at bugs.python.org  Tue Jan 14 22:51:31 2020
From: report at bugs.python.org (Tim Peters)
Date: Wed, 15 Jan 2020 03:51:31 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579060291.51.0.0679034278944.issue17005@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Oh, it's fine!  Kahn's algorithm is what I meant when I wrote the "bog-standard implementation" before.

I don't believe I've ever seen a context in real life where topsort speed made a lick of real difference, so I expect any linear-time (in the sum of the number of nodes and edges) would be fine.  Nevertheless, for recording a node's successors ("children" in your code), I've always used a list rather than a set.  Lists run faster and require less memory than sets, and - unlike sets - in Python inherently preserve insertion order.  Iteration order can become visible (e.g., if B, C, and D depend on A, what's "the" topsort order?  it depends on the order A's children appear when iterating over them - predictable with a list, "it depends" with a set).

Note:  "but we have to guard against redundant edges!" would be a red herring.  Kahn's algorithm couldn't care less, provided that predecessor counts accurately reflect the number of edges (redundant or not) entering a node.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Tue Jan 14 23:21:04 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 15 Jan 2020 04:21:04 +0000
Subject: [issue39207] concurrent.futures.ProcessPoolExecutor does not properly
 reap jobs and spawns too many workers
In-Reply-To: <1578087844.56.0.81762061225.issue39207@roundup.psfhosted.org>
Message-ID: <1579062064.11.0.524993673349.issue39207@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> It would certainly be better to start the worker processes on demand. It  probably also requires careful thought about how to detect that more workers are required.

Alright. In that case, I'll do some experimentation when I get the chance and see if I can come up with an effective way to spawn the worker processes as needed, without incurring a significant performance penalty.  

Note: I have a few other projects and obligations in the meantime, so I'm not 100% certain when I'll have the time to work on this. If anyone else is interested in working on this as well, certainly feel free to do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39207>
_______________________________________

From report at bugs.python.org  Tue Jan 14 23:24:26 2020
From: report at bugs.python.org (Michael Graczyk)
Date: Wed, 15 Jan 2020 04:24:26 +0000
Subject: [issue25872] multithreading traceback KeyError when modifying file
In-Reply-To: <1450200064.35.0.872448112145.issue25872@psf.upfronthosting.co.za>
Message-ID: <1579062266.25.0.229191162446.issue25872@roundup.psfhosted.org>


Change by Michael Graczyk <Michael at mgraczyk.com>:


----------
pull_requests: +17408
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18007

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25872>
_______________________________________

From report at bugs.python.org  Wed Jan 15 00:26:10 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 15 Jan 2020 05:26:10 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1579065970.0.0.225474912053.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

Update: I have a bit of good news and not so great news.

The good news is that I had some time to work on this again, specifically with isolating the failure in test__xxsubinterpreters.DestroyTests. Locally, I added a few temporary "@unittest.skip()" annotations to the other failing tests in an unmodified 3.8 until the only failure that would occur was the following:

======================================================================
FAIL: test_still_running (test.test__xxsubinterpreters.DestroyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aeros/repos/aeros-cpython/Lib/test/test__xxsubinterpreters.py", line 764, in test_still_running
    interpreters.destroy(interp)
AssertionError: RuntimeError not raised

----------------------------------------------------------------------

Once the failure was isolated, I applied my changes on top of that branch with the skipped tests to ensure my proposed change resolved the above failure. Unfortunately, it still occurred.

It was somewhat disappointing, but I'm certainly glad that I waited to thoroughly test the proposed changes before opening a PR. I'll continue working on this and see if I can find another fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Wed Jan 15 00:49:30 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 15 Jan 2020 05:49:30 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1579067370.45.0.629650562539.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

I also just realized that I can run "test.test__xxsubinterpreters.DestroyTests" by itself with:

./python -m test test__xxsubinterpreters.DestroyTests -j200 -F -v

For some reason, I hadn't thought of running that class of tests by itself to isolate the failure. Prior to this issue, I didn't have experience in debugging a group of intermittent failures occurring across different tests. For most bugs I've worked on so far, it was a single, clearly defined point of failure; or a behavioral issue that wasn't covered in the regression tests.

But, that's certainly useful to know for future debugging and will help to improve my workflow for further investigating this issue. It's a lot more effective than adding a bunch of skip test annotations throughout the test file!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Wed Jan 15 01:09:57 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Larivi=C3=A8re?=)
Date: Wed, 15 Jan 2020 06:09:57 +0000
Subject: [issue8800] add threading.RWLock
In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>
Message-ID: <1579068597.08.0.449173756103.issue8800@roundup.psfhosted.org>


?ric Larivi?re <ericlariviere at hotmail.com> added the comment:

Hi,

Sorry to wake up a 10 years old discussion


But I think that you might be interested in the following Python package that I created and maintain since few years now:

    https://pypi.org/project/readerwriterlock/


1- It implements the three type of reader writer lock:
  - Read Priority
  - Write Priority
  - Fair Priority

2- It matches the interface of python threading.Lock

  More specifically:
    def acquire(self, blocking: bool = True, timeout: float = -1) -> bool:
    def release(self) -> None:

As you can see it supports the 'blocking' and the 'timeout' parameters) and it uses the same methods name

3- It supports context manager (__enter__, __exit__)

4- It is also possible (currently not well documented) to provide a lock factory when initializing a new reader writer lock to specify the internal lock mechanism to use (by default it uses threading.Lock).

    def __init__(self, lock_factory: Callable[[], Lockable] = lambda: threading.Lock()) -> None:

This hidden feature allows to offer the possibility to implement your own lock mechanism (using port, file on disk, etc, ...) and the reader writer lock will internally use it (This open the door for multiprocessing locking)

----------
nosy: +elarivie
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8800>
_______________________________________

From report at bugs.python.org  Wed Jan 15 01:11:52 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 15 Jan 2020 06:11:52 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1579068712.24.0.551456002647.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> I also just realized that I can run "test.test__xxsubinterpreters.DestroyTests" by itself with:

> ./python -m test test__xxsubinterpreters.DestroyTests -j200 -F -v

Oops, the correct syntax is:

./python -m test test__xxsubinterpreters --match DestroyTests -j200 -F -v

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Wed Jan 15 02:13:06 2020
From: report at bugs.python.org (Peter Liedholm)
Date: Wed, 15 Jan 2020 07:13:06 +0000
Subject: [issue39327] shutil.rmtree using vagrant synched folder fails
In-Reply-To: <1578995152.92.0.0617677010821.issue39327@roundup.psfhosted.org>
Message-ID: <1579072386.33.0.131327232424.issue39327@roundup.psfhosted.org>


Peter Liedholm <peterfromswe884 at gmail.com> added the comment:

Problem is also reported in virtualbox
https://www.virtualbox.org/ticket/19004

>From that ticket some more analysis is done;
strace reveals that Python has kept an open fd for the directory being removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39327>
_______________________________________

From report at bugs.python.org  Wed Jan 15 02:20:48 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Wed, 15 Jan 2020 07:20:48 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1579072848.56.0.254568201766.issue37224@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

I just made a rather interesting discovery. Instead of specifically focusing my efforts on the logic with interp_destroy(), I decided to take a closer look at the failing unit test itself. 

The main test within DestroyTests that's failing is the following:

```
    def test_still_running(self):
        main, = interpreters.list_all()
        interp = interpreters.create()
        with _running(interp):
            with self.assertRaises(RuntimeError):
                interpreters.destroy(interp)
            self.assertTrue(interpreters.is_running(interp))
```

(Specifically, "self.assertRaises(RuntimeError): interpreters.destroy(interp)" is the main point of failure)

In order to be 100% certain that it was an issue occurring from interpreters.destroy(), I decided to add in a bit of a "sanity check" to ensure the interpreter was actually running in the first place before destroying it (I also added some extra debugging info):

```
    def test_still_running(self):
        main, = interpreters.list_all()
        interp = interpreters.create()
        with _running(interp):
            self.assertTrue(interpreters.is_running(interp),
                msg=f"Interp {interp} should be running before destruction.")

            with self.assertRaises(RuntimeError,
                msg=f"Should not be able to destroy interp {interp} while"
                           " it's still running."):
                interpreters.destroy(interp)

            self.assertTrue(interpreters.is_running(interp))
```

The results were very interesting...

```
OK
0:00:49 load avg: 135.49 [306/1] test__xxsubinterpreters failed
test_all (test.test__xxsubinterpreters.DestroyTests) ... ok
test_already_destroyed (test.test__xxsubinterpreters.DestroyTests) ... ok
test_bad_id (test.test__xxsubinterpreters.DestroyTests) ... ok
test_does_not_exist (test.test__xxsubinterpreters.DestroyTests) ... ok
test_from_current (test.test__xxsubinterpreters.DestroyTests) ... ok
test_from_other_thread (test.test__xxsubinterpreters.DestroyTests) ... ok
test_from_sibling (test.test__xxsubinterpreters.DestroyTests) ... ok
test_main (test.test__xxsubinterpreters.DestroyTests) ... ok
test_one (test.test__xxsubinterpreters.DestroyTests) ... ok
test_still_running (test.test__xxsubinterpreters.DestroyTests) ... FAIL

======================================================================
FAIL: test_still_running (test.test__xxsubinterpreters.DestroyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aeros/repos/aeros-cpython/Lib/test/test__xxsubinterpreters.py", line 763, in test_still_running
    self.assertTrue(interpreters.is_running(interp),
AssertionError: False is not true : Interp 12 should be running before destruction.

----------------------------------------------------------------------
```

As can be seen from the results above, the interpreter is not even running in the first place before it's destroyed, so of course destroy() won't raise an RuntimeError. I think this proves that interpreters.destroy() is _not_ where we should be focusing our efforts (at least for now). Instead, we should first investigate why it's not even running at this point. I suspect the issue _might_ be a race condition within the "_running()" context manager that's preventing the interpreter from being ran, but I'll have to do some further investigation.

I also ran this ~20 times to be 100% certain, and every single one of those times the point of failure was at the new assertion check I added before destroy(). 

Notably, a rather difficult and hard to explain side effect occurred from adding the new assertion. The average number of tests before failure increased by a significant amount. In the above test, it was able to pass 306 iterations before failing, and in one of my earlier tests it reached over 1000. 

That never happened before on the 3.8 branch, it would very consistently fail in the first set of parallel workers if not very soon after. I can say that with a degree certainty as well, since I've ran this set of tests a countless number of times while trying to debug the failure. But, I have no explanation for this.

Do you have any potential ideas, Eric? Also, do you think it might be worth adding in the changes I made to DestroyTests.test_still_running above? It doesn't directly address the core failure occurring, but I think it improves the test significantly; both in functionality and debugging info. I would be glad to open a PR if you think the test changes might be useful, as well as make any needed adjustments to them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Wed Jan 15 03:24:17 2020
From: report at bugs.python.org (ss)
Date: Wed, 15 Jan 2020 08:24:17 +0000
Subject: [issue39339] Exception in thread QueueManagerThread
Message-ID: <1579076657.65.0.185497149152.issue39339@roundup.psfhosted.org>


New submission from ss <1162276945 at qq.com>:

os.cpu_count() is 64, but 61 to 64 raise Exception in thread QueueManagerThread Error: ValueError: need at most 63 handles, got a sequence of length 63.

----------
components: Windows
messages: 360030
nosy: paul.moore, pythonpython, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Exception in thread QueueManagerThread
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39339>
_______________________________________

From report at bugs.python.org  Wed Jan 15 03:25:46 2020
From: report at bugs.python.org (ss)
Date: Wed, 15 Jan 2020 08:25:46 +0000
Subject: [issue39339] ProcessPoolExecutor() Exception in thread
 QueueManagerThread
In-Reply-To: <1579076657.65.0.185497149152.issue39339@roundup.psfhosted.org>
Message-ID: <1579076746.63.0.590551549031.issue39339@roundup.psfhosted.org>


Change by ss <1162276945 at qq.com>:


----------
title: Exception in thread QueueManagerThread -> ProcessPoolExecutor()   Exception in thread QueueManagerThread

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39339>
_______________________________________

From report at bugs.python.org  Wed Jan 15 04:20:07 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 15 Jan 2020 09:20:07 +0000
Subject: [issue8800] add threading.RWLock
In-Reply-To: <1274694942.46.0.488506239249.issue8800@psf.upfronthosting.co.za>
Message-ID: <1579080007.05.0.499080058374.issue8800@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks for sharing, your project looks viable!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8800>
_______________________________________

From report at bugs.python.org  Wed Jan 15 04:21:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 09:21:26 +0000
Subject: [issue39164] Add private _PyErr_GetExcInfo() function which accepts a
 tstate argument
In-Reply-To: <1577702198.9.0.00483910121214.issue39164@roundup.psfhosted.org>
Message-ID: <1579080086.78.0.955479465987.issue39164@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17409
pull_request: https://github.com/python/cpython/pull/18010

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39164>
_______________________________________

From report at bugs.python.org  Wed Jan 15 04:31:57 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 15 Jan 2020 09:31:57 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1579080716.98.0.930718092906.issue39310@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Brett]

> Can I just say that "ulp" is totally non-obvious what that even means unless you have a specific math background?

It's a good point. I guess we have a choice between using the domain-specific standard-ish name (which should be immediately meaningful to experts, but doesn't give much of a hint to non-experts) or using something more descriptive (which then risks confusing experts until they figure out "oh, that's just ulp").

There's also the option of spelling it out as "unit_in_last_place", but I'm not sure that benefits anyone.

For meaningful descriptive names, "float_resolution" or "gap_to_next" are about the best I can come up with. "precision" is too ambiguous.

NumPy has "numpy.spacing". But this exhibits exactly the trap of *not* using the "ulp" name: on a first glance, I incorrectly decided that NumPy *didn't* implement a ulp function. Then, having found `numpy.spacing`, I had to read the description carefully in order to recognise that "oh, this is just ulp". (Actually, I had to do more, since the description doesn't make all the corner cases clear, and in fact is currently wrong for powers of 2.)

If we can get people can coalesce around a preferred alternative name, we could consider changing this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Wed Jan 15 04:35:33 2020
From: report at bugs.python.org (Peter Liedholm)
Date: Wed, 15 Jan 2020 09:35:33 +0000
Subject: [issue39340] shutil.rmtree and write protected files
Message-ID: <1579080933.31.0.376881618975.issue39340@roundup.psfhosted.org>


New submission from Peter Liedholm <peterfromswe884 at gmail.com>:

Ubuntu 18.4 and Windows 7 has different behaviour when deleting write protected files with rmtree.

Ubuntu silently deletes them (unexpected?)
Windows moans about access denied (expected?)

Reproduction method linux
mkdir test; touch test/file.txt; chmod -w test/file.txt

Reproduction method windows
mkdir test && type nul > test\file.txt && attrib +R test\file.txt

Reproduction method cont.
python3 -c "import shutil; shutil.rmtree('test')"

----------
components: Library (Lib)
messages: 360033
nosy: PeterFS
priority: normal
severity: normal
status: open
title: shutil.rmtree and write protected files
versions: Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39340>
_______________________________________

From report at bugs.python.org  Wed Jan 15 04:57:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 09:57:18 +0000
Subject: [issue39341] zipfile: ZIP Bomb vulnerability,
 don't check announced uncompressed size
Message-ID: <1579082238.3.0.125873650379.issue39341@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Laish, Amit (GE Digital) reported a vulnerability in the zipfile module to the PSRT list. The module is vulnerable to ZIP Bomb:
https://en.wikipedia.org/wiki/Zip_bomb

A 100 KB malicious ZIP file announces an uncompressed size of 1 byte but extracting it writes 100 MB on disk.

Python 2.7 is vulnerable.

Python 3.7 does not seem to be directly vulnerable. The proof of concept fails with:

$ python3 poc.py 
The size of the uncompressed data is: 1 bytes
Traceback (most recent call last):
  File "poc.py", line 18, in <module>
    extract() # The uncompressed size is more than 20GB :)
  File "poc.py", line 6, in extract
    zip_ref.extractall('./')
  File "/usr/lib64/python3.7/zipfile.py", line 1636, in extractall
    self._extract_member(zipinfo, path, pwd)
  File "/usr/lib64/python3.7/zipfile.py", line 1691, in _extract_member
    shutil.copyfileobj(source, target)
  File "/usr/lib64/python3.7/shutil.py", line 79, in copyfileobj
    buf = fsrc.read(length)
  File "/usr/lib64/python3.7/zipfile.py", line 930, in read
    data = self._read1(n)
  File "/usr/lib64/python3.7/zipfile.py", line 1020, in _read1
    self._update_crc(data)
  File "/usr/lib64/python3.7/zipfile.py", line 948, in _update_crc
    raise BadZipFile("Bad CRC-32 for file %r" % self.name)
zipfile.BadZipFile: Bad CRC-32 for file 'dummy1.txt'

The malicious ZIP file size is 100 KB. Extracting it writes dummy1.txt: 100 MB only made of a single character "0" (zero, Unicode character U+0030 or byte 0x30) repeated on 100 MB.

The original proof of concept used a 20 MB ZIP writing 20 GB on disk. It's just the same text file repeated 200 files. I created a smaller ZIP just to be able to upload it to bugs.python.org.

Attached files:

* create_zip.py: created malicious.zip from valid.zip: modify the uncompressed size of compressed dummy1.txt
* valid.zip: compressed dummy1.txt, file size is 100 KB
* poc.py: extract malicious.zip

--

The zipfile documentation describes "Decompression pitfalls":
https://docs.python.org/dev/library/zipfile.html#decompression-pitfalls

The zlib.decompress() function has a max_length parameter:
https://docs.python.org/dev/library/zlib.html#zlib.Decompress.decompress

See also my notes on "Archives and Zip Bomb":
https://python-security.readthedocs.io/security.html#archives-and-zip-bomb

--

unzip program of Fedora unzip-6.0-44.fc31.x86_64 package has the same vulnerability:

$ unzip malicious.zip 
Archive:  malicious.zip
  inflating: dummy1.txt 

$ unzip -l malicious.zip 
Archive:  malicious.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
        1  03-12-2019 14:10   dummy1.txt
---------                     -------
        1                     1 file

--

According to Riccardo Schirone (Red Hat), p7zip, on the other hand, seems to use the minimum value between the header value and the file one, so it extracts only 1 byte and correctly complains about CRC failures.

----------
components: Library (Lib)
messages: 360034
nosy: vstinner
priority: normal
severity: normal
status: open
title: zipfile: ZIP Bomb vulnerability, don't check announced uncompressed size
type: security
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39341>
_______________________________________

From report at bugs.python.org  Wed Jan 15 04:58:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 09:58:21 +0000
Subject: [issue39341] zipfile: ZIP Bomb vulnerability,
 don't check announced uncompressed size
In-Reply-To: <1579082238.3.0.125873650379.issue39341@roundup.psfhosted.org>
Message-ID: <1579082301.38.0.333824234974.issue39341@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


Added file: https://bugs.python.org/file48843/create_zip.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39341>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:00:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 10:00:24 +0000
Subject: [issue39341] zipfile: ZIP Bomb vulnerability,
 don't check announced uncompressed size
In-Reply-To: <1579082238.3.0.125873650379.issue39341@roundup.psfhosted.org>
Message-ID: <1579082424.08.0.343401471795.issue39341@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


Added file: https://bugs.python.org/file48844/poc.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39341>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:00:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 10:00:35 +0000
Subject: [issue39341] zipfile: ZIP Bomb vulnerability,
 don't check announced uncompressed size
In-Reply-To: <1579082238.3.0.125873650379.issue39341@roundup.psfhosted.org>
Message-ID: <1579082435.01.0.442342251729.issue39341@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


Added file: https://bugs.python.org/file48845/malicious.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39341>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:00:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 10:00:52 +0000
Subject: [issue39341] [security] zipfile: ZIP Bomb vulnerability,
 don't check announced uncompressed size
In-Reply-To: <1579082238.3.0.125873650379.issue39341@roundup.psfhosted.org>
Message-ID: <1579082452.58.0.718732134464.issue39341@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +christian.heimes, rschiron
title: zipfile: ZIP Bomb vulnerability, don't check announced uncompressed size -> [security] zipfile: ZIP Bomb vulnerability, don't check announced uncompressed size

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39341>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:03:00 2020
From: report at bugs.python.org (Chris Burr)
Date: Wed, 15 Jan 2020 10:03:00 +0000
Subject: [issue39342] Expose X509_V_FLAG_ALLOW_PROXY_CERTS in ssl
Message-ID: <1579082580.52.0.275703305608.issue39342@roundup.psfhosted.org>


New submission from Chris Burr <christopher.burr at cern.ch>:

Enabling proxy certificate validation requires X509_V_FLAG_ALLOW_PROXY_CERTS to be included in the verify flags.[1] This should be exposed as ssl.VERIFY_ALLOW_PROXY_CERTS to match with the other X509_V_FLAG_* variables.

https://www.openssl.org/docs/man1.1.1/man7/proxy-certificates.html

----------
components: Library (Lib)
messages: 360035
nosy: chrisburr
priority: normal
severity: normal
status: open
title: Expose X509_V_FLAG_ALLOW_PROXY_CERTS in ssl
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39342>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:03:11 2020
From: report at bugs.python.org (Chris Burr)
Date: Wed, 15 Jan 2020 10:03:11 +0000
Subject: [issue39342] Expose X509_V_FLAG_ALLOW_PROXY_CERTS in ssl
In-Reply-To: <1579082580.52.0.275703305608.issue39342@roundup.psfhosted.org>
Message-ID: <1579082591.88.0.453892611021.issue39342@roundup.psfhosted.org>


Change by Chris Burr <christopher.burr at cern.ch>:


----------
assignee:  -> christian.heimes
components: +SSL -Library (Lib)
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39342>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:06:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 10:06:21 +0000
Subject: [issue39341] [security] zipfile: ZIP Bomb vulnerability,
 don't check announced uncompressed size
In-Reply-To: <1579082238.3.0.125873650379.issue39341@roundup.psfhosted.org>
Message-ID: <1579082781.72.0.0967802895612.issue39341@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Amit Laish reported the exact same vulnerability to rubyzip and they released a fix for it, CVE-2019-16892.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39341>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:12:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 10:12:31 +0000
Subject: [issue39341] [security] zipfile: ZIP Bomb vulnerability,
 don't check announced uncompressed size
In-Reply-To: <1579082238.3.0.125873650379.issue39341@roundup.psfhosted.org>
Message-ID: <1579083151.37.0.581430727947.issue39341@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Is this issue a duplicate of bpo-36260 "[security] CVE-2019-9674: Zip Bomb vulnerability" which has been closed by documenting the issue (without touching zipfile.py)?

The zipfile documentation now contains an explicit warning against ZIP bombs:

"""
Resources limitations

The lack of memory or disk volume would lead to decompression failed. For example, decompression bombs (aka ZIP bomb) apply to zipfile library that can cause disk volume exhaustion.
"""

https://docs.python.org/dev/library/zipfile.html#resources-limitations

Note: bpo-36462 "CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py" was closed as duplicate of bpo-36260.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39341>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:15:58 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 15 Jan 2020 10:15:58 +0000
Subject: [issue39341] [security] zipfile: ZIP Bomb vulnerability,
 don't check announced uncompressed size
In-Reply-To: <1579082238.3.0.125873650379.issue39341@roundup.psfhosted.org>
Message-ID: <1579083358.58.0.344099002004.issue39341@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also some discussion on regarding this class of vulnerability : https://bugs.python.org/issue36260

----------
nosy: +serhiy.storchaka, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39341>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:18:42 2020
From: report at bugs.python.org (Chris Burr)
Date: Wed, 15 Jan 2020 10:18:42 +0000
Subject: [issue39342] Expose X509_V_FLAG_ALLOW_PROXY_CERTS in ssl
In-Reply-To: <1579082580.52.0.275703305608.issue39342@roundup.psfhosted.org>
Message-ID: <1579083522.76.0.694516140791.issue39342@roundup.psfhosted.org>


Change by Chris Burr <christopher.burr at cern.ch>:


----------
keywords: +patch
pull_requests: +17410
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18011

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39342>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:22:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 10:22:54 +0000
Subject: [issue39343] Travis CI: documentation job fails in
 library/nntplib.rst with random network issue on news.gmane.io
Message-ID: <1579083774.85.0.947952738007.issue39343@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Should we disable documentation test on nntplib? It's surprising that test_nntplib test on the other Travis CI jobs.

https://travis-ci.org/python/cpython/jobs/637325027

Warning, treated as error:

**********************************************************************

File "library/nntplib.rst", line ?, in default

Failed example:

    s = NNTP('news.gmane.io')

Exception raised:

    Traceback (most recent call last):

      File "/home/travis/build/python/cpython/Lib/doctest.py", line 1329, in __run

        exec(compile(example.source, filename, "single",

      File "<doctest default[0]>", line 1, in <module>

        s = NNTP('news.gmane.io')

      File "/home/travis/build/python/cpython/Lib/nntplib.py", line 1045, in __init__

        self.sock = self._create_socket(timeout)

      File "/home/travis/build/python/cpython/Lib/nntplib.py", line 1062, in _create_socket

        return socket.create_connection((self.host, self.port), timeout)

      File "/home/travis/build/python/cpython/Lib/socket.py", line 843, in create_connection

        raise err

      File "/home/travis/build/python/cpython/Lib/socket.py", line 831, in create_connection

        sock.connect(sa)

    ConnectionRefusedError: [Errno 111] Connection refused

----------
components: Tests
messages: 360039
nosy: vstinner
priority: normal
severity: normal
status: open
title: Travis CI: documentation job fails in library/nntplib.rst with random network issue on news.gmane.io
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39343>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:30:40 2020
From: report at bugs.python.org (Robert Xiao)
Date: Wed, 15 Jan 2020 10:30:40 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1579084240.25.0.045989438861.issue39318@roundup.psfhosted.org>


Robert Xiao <nneonneo at gmail.com> added the comment:

Could this be solvable if `closefd` were a writable attribute? Then we could do

    file = None
    try:
        file = io.open(fd, ..., closefd=False)
        file.closefd = True
    except:
        if file and not file.closefd:
            os.close(fd)
        raise

I believe this should be bulletproof - a KeyboardInterrupt can happen anywhere in the `try` and we will not leak or double-close. Either file.closefd is set, in which case `file` owns the fd and will close it eventually, or file.closefd is not set in which case the fd needs to be manually closed, or file doesn't exist (exception thrown in io.open or while assigning file), in which case the fd still needs to be manually closed.

Of course, this can leak if a KeyboardInterrupt lands in the `except` - but that's not something we can meaningfully deal with. The important thing is that this shouldn't double-close if I analyzed it correctly.

This is a somewhat annoying pattern, though. I wonder if there's a nicer way to implement it so we don't end up with this kind of boilerplate everywhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:37:44 2020
From: report at bugs.python.org (Albert Zeyer)
Date: Wed, 15 Jan 2020 10:37:44 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1579084664.6.0.509220255203.issue39318@roundup.psfhosted.org>


Albert Zeyer <albzey at googlemail.com> added the comment:

If you anyway accept that KeyboardInterrupt can potentially leak, by just using `except Exception`, it would also be solved here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:51:56 2020
From: report at bugs.python.org (Amelia smith)
Date: Wed, 15 Jan 2020 10:51:56 +0000
Subject: [issue35058] Unable to Install Python on Windows
In-Reply-To: <1540390509.38.0.788709270274.issue35058@psf.upfronthosting.co.za>
Message-ID: <1579085516.95.0.374349851547.issue35058@roundup.psfhosted.org>


Amelia smith <amelia01smith at gmail.com> added the comment:

Steps to canon printer error b200  Fix by Canon Support. Dial Tollfree +1-800-570-3215 To Fix group b200 mistake, Canon Printer Error B200.
printersupport24x7.com/questions/how-to-fix-canon-printer-error-b200/

----------
nosy: +ameliasmith010

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35058>
_______________________________________

From report at bugs.python.org  Wed Jan 15 05:52:49 2020
From: report at bugs.python.org (Amelia smith)
Date: Wed, 15 Jan 2020 10:52:49 +0000
Subject: [issue35058] Unable to Install Python on Windows
In-Reply-To: <1540390509.38.0.788709270274.issue35058@psf.upfronthosting.co.za>
Message-ID: <1579085569.06.0.977294389731.issue35058@roundup.psfhosted.org>


Amelia smith <amelia01smith at gmail.com> added the comment:

Steps to canon printer error b200  Fix by Canon Support .Dial Tollfree +1-800-570-3215 To Fix group b200 mistake, Canon Printer Error B200.
https://www.printersupport24x7.com/questions/how-to-fix-canon-printer-error-b200/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35058>
_______________________________________

From report at bugs.python.org  Wed Jan 15 07:00:36 2020
From: report at bugs.python.org (Mario Corchero)
Date: Wed, 15 Jan 2020 12:00:36 +0000
Subject: [issue39222] unittest.mock.Mock.parent is broken or undocumented
In-Reply-To: <1578236312.03.0.58171840403.issue39222@roundup.psfhosted.org>
Message-ID: <1579089636.5.0.635122348755.issue39222@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

> My suggestion would be to add `parent` to the docs @xtreak links to as a way to resolve this issue.

+1, we should probably add it on the docs of the constructor here https://docs.python.org/3/library/unittest.mock.html#unittest.mock.Mock as it is done for name and having a section like the on for name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39222>
_______________________________________

From report at bugs.python.org  Wed Jan 15 07:01:19 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 15 Jan 2020 12:01:19 +0000
Subject: [issue39341] [security] zipfile: ZIP Bomb vulnerability,
 don't check announced uncompressed size
In-Reply-To: <1579082238.3.0.125873650379.issue39341@roundup.psfhosted.org>
Message-ID: <1579089679.55.0.837146193292.issue39341@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is this 2.7 only issue? I think it is too late.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39341>
_______________________________________

From report at bugs.python.org  Wed Jan 15 07:09:24 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 15 Jan 2020 12:09:24 +0000
Subject: [issue39340] shutil.rmtree and write protected files
In-Reply-To: <1579080933.31.0.376881618975.issue39340@roundup.psfhosted.org>
Message-ID: <1579090164.29.0.241499077943.issue39340@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I'm not certain exactly what you want Python to be doing here, but let's start out by clarifying some concepts.

> Reproduction method linux
> mkdir test; touch test/file.txt; chmod -w test/file.txt

Unlinking a file requires write permission to the parent directory, since that's what's getting directly modified. Indirectly, if it's the last link to the file, then the file itself gets deleted. But Unix has no delete permission on individual files. You may have been misled into thinking so by bash, which requests confirmation when unlinking a file that lacks write permission. 

That said, some Linux filesystems implement an [i]mmutable file attribute (e.g. chattr +i test/file.txt). Unlinking an immutable file is completely disallowed, so Linux requires super-user access to modify this file attribute. In practice, we can differentiate the two cases by the errno value. If the parent directory doesn't allow write access, the error is EACCES. But if the file is immutable, the error is EPERM. 

> Reproduction method windows
> mkdir test && type nul > test\file.txt && attrib +R test\file.txt

In Windows, delete access (actually delete/rename access, i.e. unlink/relink) is separate from write access.

For all filesystems, a file's share-access control trumps everything else. If previous opens do not share delete access, a request for delete access fails as a sharing violation (32).

Else if the user's access token has SeRestorePrivilege enabled, then delete access will be granted. Actually, the file open also has to request backup semantics for this privilege to apply, but the internal open used by WINAPI DeleteFileW does this for us.

Else if the parent directory grants delete-child access to the user or one of the user's enabled groups, then the user is granted delete access to the file. 

Else the discretionary access control on a file may grant or deny delete access -- if it's also allowed by mandatory access control. Delete access will not be granted if the file's mandatory label denies write-up access and the label is at a higher integrity level (defaults to medium) than that of the user's access token (defaults to medium).

Windows filesystems also support a readonly file attribute. We can open a readonly file for delete access, which has to be allowed because Windows allows renaming (relinking) a readonly file. However when we try to set a readonly file's delete disposition, such as via SetFileInformationByHandle: FileDispositionInfo, the request will fail with access denied (5). (Actually, at the lower-level NT API level, this case is STATUS_CANNOT_DELETE, which is differentiated from STATUS_ACCESS_DENIED, but the Windows API aggregates them.) Normally this two-step open/delete process is wrapped up in a single call such as DeleteFileW. However, if you're using the two-step process directly, note that Windows 10 has a new disposition flag to ignore the readonly attribute: FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39340>
_______________________________________

From report at bugs.python.org  Wed Jan 15 07:15:56 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 15 Jan 2020 12:15:56 +0000
Subject: [issue39303] Refactor cmd module
In-Reply-To: <1578736336.99.0.232991806531.issue39303@roundup.psfhosted.org>
Message-ID: <1579090556.59.0.148012861821.issue39303@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Dan, thank you for your contribution.  Please see the pull request for the motivation behind closing this.

----------
nosy: +cheryl.sabella
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39303>
_______________________________________

From report at bugs.python.org  Wed Jan 15 07:39:22 2020
From: report at bugs.python.org (Gisle Vanem)
Date: Wed, 15 Jan 2020 12:39:22 +0000
Subject: [issue33351] Support compiling with clang-cl on Windows
In-Reply-To: <1524631004.17.0.682650639539.issue33351@psf.upfronthosting.co.za>
Message-ID: <1579091962.33.0.0422172198691.issue33351@roundup.psfhosted.org>


Gisle Vanem <gvanem at yahoo.no> added the comment:

I will add to this issue my *only* compile problem I had using clang-cl ver 9. It has an issue with parsing the `frame_t` structure in Modules/_tracemalloc.c:

Modules/_tracemalloc.c(64,11): error: declaration of anonymous struct must be a definition
  typedef struct
          ^
Modules/_tracemalloc.c(64,3): warning: typedef requires a name [-Wmissing-declarations]
  typedef struct
  ^~~~~~~
Modules/_tracemalloc.c(77,11): warning: #pragma pack(pop, ...) failed: stack empty [-Wignored-pragmas]
  #pragma pack(pop)
          ^
Modules/_tracemalloc.c(110,5): error: unknown type name 'frame_t'
    frame_t frames[1];
    ^
------------------

I commented on and suggested a fix for _tracemalloc.c here:
https://github.com/python/cpython/commit/8d59eb1b66c51b2b918da9881c57d07d08df43b7#r36794938

----------
nosy: +gvanem
type: enhancement -> compile error
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33351>
_______________________________________

From report at bugs.python.org  Wed Jan 15 07:45:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 12:45:45 +0000
Subject: [issue39164] Add private _PyErr_GetExcInfo() function which accepts a
 tstate argument
In-Reply-To: <1577702198.9.0.00483910121214.issue39164@roundup.psfhosted.org>
Message-ID: <1579092345.92.0.7393355408.issue39164@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 3f12ac18a407983a23d43ae785e805e773571477 by Victor Stinner in branch 'master':
bpo-39164: Fix compiler warning in PyErr_GetExcInfo() (GH-18010)
https://github.com/python/cpython/commit/3f12ac18a407983a23d43ae785e805e773571477


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39164>
_______________________________________

From report at bugs.python.org  Wed Jan 15 07:58:40 2020
From: report at bugs.python.org (Pedja)
Date: Wed, 15 Jan 2020 12:58:40 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
In-Reply-To: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>
Message-ID: <1579093120.65.0.103280359843.issue35665@roundup.psfhosted.org>


Pedja <pedja at supurovic.net> added the comment:

This is still an issue. Serious one. People are unable to just remove this certificate as it is needed for everyday use.

It is reasonable that application does not deal with invalid certificates. 
I can understand application to breaks if one tries to use invalid certificate. 

But this is not that case. Application breaks on just enumerating certificates even if it does not need it at all.

It is advisable for application just to skip and ignore invalid certificate unless it is required for application to work.

Please reconsider action on this issue to prevent application breaking when it is not necessary.

----------
nosy: +pedja

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35665>
_______________________________________

From report at bugs.python.org  Wed Jan 15 08:00:57 2020
From: report at bugs.python.org (Patrick Buxton)
Date: Wed, 15 Jan 2020 13:00:57 +0000
Subject: [issue39104] ProcessPoolExecutor hangs on shutdown nowait with
 pickling failure
In-Reply-To: <1576824742.02.0.740148547005.issue39104@roundup.psfhosted.org>
Message-ID: <1579093257.45.0.574580475828.issue39104@roundup.psfhosted.org>


Patrick Buxton <patrick.buxton at tartansolutions.com> added the comment:

Added core developer to get some feedback

----------
nosy: +patbuxton, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39104>
_______________________________________

From report at bugs.python.org  Wed Jan 15 08:01:12 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 15 Jan 2020 13:01:12 +0000
Subject: [issue39343] Travis CI: documentation job fails in
 library/nntplib.rst with random network issue on news.gmane.io
In-Reply-To: <1579083774.85.0.947952738007.issue39343@roundup.psfhosted.org>
Message-ID: <1579093272.62.0.710440584689.issue39343@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39343>
_______________________________________

From report at bugs.python.org  Wed Jan 15 08:06:05 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 15 Jan 2020 13:06:05 +0000
Subject: [issue39343] Travis CI: documentation job fails in
 library/nntplib.rst with random network issue on news.gmane.io
In-Reply-To: <1579083774.85.0.947952738007.issue39343@roundup.psfhosted.org>
Message-ID: <1579093565.93.0.862249974848.issue39343@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Same for news.gmane.org

>>> s = nntplib.NNTP('news.gmane.org')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/corona10/oss/cpython/Lib/nntplib.py", line 1045, in __init__
    self.sock = self._create_socket(timeout)
  File "/Users/corona10/oss/cpython/Lib/nntplib.py", line 1062, in _create_socket
    return socket.create_connection((self.host, self.port), timeout)
  File "/Users/corona10/oss/cpython/Lib/socket.py", line 843, in create_connection
    raise err
  File "/Users/corona10/oss/cpython/Lib/socket.py", line 831, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 61] Connection refused

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39343>
_______________________________________

From report at bugs.python.org  Wed Jan 15 08:18:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 13:18:10 +0000
Subject: [issue39341] [security] zipfile: ZIP Bomb vulnerability,
 don't check announced uncompressed size
In-Reply-To: <1579082238.3.0.125873650379.issue39341@roundup.psfhosted.org>
Message-ID: <1579094290.51.0.555838262537.issue39341@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Is this 2.7 only issue? I think it is too late.

I vaguely recall that Christian Heimes wrote something about Python 3 in a private email, but I cannot find this email anymore :-p In case of doubt, I marked Python 3 as affected as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39341>
_______________________________________

From report at bugs.python.org  Wed Jan 15 08:24:52 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 15 Jan 2020 13:24:52 +0000
Subject: [issue35058] Unable to Install Python on Windows
In-Reply-To: <1540390509.38.0.788709270274.issue35058@psf.upfronthosting.co.za>
Message-ID: <1579094691.99.0.296470883424.issue35058@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg360042

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35058>
_______________________________________

From report at bugs.python.org  Wed Jan 15 08:25:00 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 15 Jan 2020 13:25:00 +0000
Subject: [issue35058] Unable to Install Python on Windows
In-Reply-To: <1540390509.38.0.788709270274.issue35058@psf.upfronthosting.co.za>
Message-ID: <1579094700.75.0.846693070842.issue35058@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg360043

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35058>
_______________________________________

From report at bugs.python.org  Wed Jan 15 08:28:11 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 15 Jan 2020 13:28:11 +0000
Subject: [issue39343] Travis CI: documentation job fails in
 library/nntplib.rst with random network issue on news.gmane.io
In-Reply-To: <1579083774.85.0.947952738007.issue39343@roundup.psfhosted.org>
Message-ID: <1579094891.09.0.124253787516.issue39343@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

s = nntplib.NNTP('nntp.perl.org')
s = nntplib.NNTP('news.mozilla.org')

I 've checked a few servers list to use.
But I don't know that they are proper to use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39343>
_______________________________________

From report at bugs.python.org  Wed Jan 15 08:35:53 2020
From: report at bugs.python.org (Ajaya)
Date: Wed, 15 Jan 2020 13:35:53 +0000
Subject: [issue39344] Getting error while importing ssl " import _ssl # if we
 can't import it,
 let the error propagate ImportError: DLL load failed while importing _ssl: The
 specified module could not be found."
Message-ID: <1579095353.91.0.817394645763.issue39344@roundup.psfhosted.org>


New submission from Ajaya <ajayakumars265 at gmail.com>:

We have built python3.7.5 and python3.8.1 source code in windows 10 machine. I have created an embedded interptreter where i am trying to "import ssl" but it is failing with error "Journal execution results for D:\workdir\PR\9616145\9616145\journal.py...
Syntax errors:
Line 98: Traceback (most recent call last):
  File "D:\workdir\PR\9616145\9616145\journal.py", line 1, in <module>
    import ssl
  File "<frozen zipimport>", line 259, in load_module
  File "D:\workdir\PR\PRUnits\PythonIssuefix381\wntx64\kits\nxbin\python\Python38.zip\ssl.py", line 98, in <module>
    import _ssl             # if we can't import it, let the error propagate
ImportError: DLL load failed while importing _ssl: The specified module could not be found."

This error was coming from python 3.7.4 and it was working fine till python 3.7.3. 

There is also one work around if i replaced _ssl.pyd with python3.7.3 _ssl.pyd it is working fine. I also found python 3.7.3 is using openssl-1.1.1c where as python3.7.5 and python3.8.1 is using openssl- 1.1.1d.

I have also checked in using python 3.7.5  installing  and import ssl is working fine. I have also checked that _ssl.pyd in installer  and _ssl.pyd is created by manually built size is different.

I am not getting the exact root cause what has happened. Could you please me i have already stucked  and not able to work.

----------
components: Windows
files: journal.py
messages: 360055
nosy: Ajaya, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Getting error while importing ssl " import _ssl             # if we can't import it, let the error propagate ImportError: DLL load failed while importing _ssl: The specified module could not be found."
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48846/journal.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39344>
_______________________________________

From report at bugs.python.org  Wed Jan 15 08:59:48 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Wed, 15 Jan 2020 13:59:48 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1579096788.5.0.220637243394.issue35943@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

The changes required to successfully do this backport are many and affect critical areas. I am not in a hurry to do this. If anyone else wants to take this up quickly, please do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Wed Jan 15 10:29:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 15:29:47 +0000
Subject: [issue38858] new_interpreter() should reuse more
 Py_InitializeFromConfig() code
In-Reply-To: <1574205069.59.0.0921100013632.issue38858@roundup.psfhosted.org>
Message-ID: <1579102187.76.0.142719686011.issue38858@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

FYI this change broke librepo which calls PyLong_FromLong() without holding the GIL. In Python 3.8, "it works". In Python 3.9, it does crash: get_small_int() gets a NULL tstate and then dereference a NULL pointer.

librepo bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1788918

IMHO it's a bug in librepo: the GIL must be held to use Python C API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38858>
_______________________________________

From report at bugs.python.org  Wed Jan 15 10:31:11 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 15 Jan 2020 15:31:11 +0000
Subject: [issue39343] Travis CI: documentation job fails in
 library/nntplib.rst with random network issue on news.gmane.io
In-Reply-To: <1579083774.85.0.947952738007.issue39343@roundup.psfhosted.org>
Message-ID: <1579102271.82.0.753936305095.issue39343@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

But for now on, IMHO skip is better choice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39343>
_______________________________________

From report at bugs.python.org  Wed Jan 15 10:43:54 2020
From: report at bugs.python.org (SilentGhost)
Date: Wed, 15 Jan 2020 15:43:54 +0000
Subject: [issue39344] Getting error while importing ssl " import _ssl # if we
 can't import it,
 let the error propagate ImportError: DLL load failed while importing _ssl: The
 specified module could not be found."
In-Reply-To: <1579095353.91.0.817394645763.issue39344@roundup.psfhosted.org>
Message-ID: <1579103034.64.0.436762297801.issue39344@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
assignee:  -> christian.heimes
components: +SSL
nosy: +christian.heimes
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39344>
_______________________________________

From report at bugs.python.org  Wed Jan 15 10:53:20 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 15 Jan 2020 15:53:20 +0000
Subject: [issue39343] Travis CI: documentation job fails in
 library/nntplib.rst with random network issue on news.gmane.io
In-Reply-To: <1579083774.85.0.947952738007.issue39343@roundup.psfhosted.org>
Message-ID: <1579103600.28.0.37387287143.issue39343@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17411
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18013

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39343>
_______________________________________

From report at bugs.python.org  Wed Jan 15 11:03:08 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 15 Jan 2020 16:03:08 +0000
Subject: [issue39344] Getting error while importing ssl " import _ssl # if we
 can't import it,
 let the error propagate ImportError: DLL load failed while importing _ssl: The
 specified module could not be found."
In-Reply-To: <1579095353.91.0.817394645763.issue39344@roundup.psfhosted.org>
Message-ID: <1579104188.83.0.557029470285.issue39344@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

It sounds like Python cannot load the OpenSSL DLLs or a dependency of the OpenSSL DLLs. IIRC the libraries are called libssl.dll and libcrypto.dll. The files must be in the current DLL search path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39344>
_______________________________________

From report at bugs.python.org  Wed Jan 15 11:13:37 2020
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 15 Jan 2020 16:13:37 +0000
Subject: [issue35058] Unable to Install Python on Windows
In-Reply-To: <1540390509.38.0.788709270274.issue35058@psf.upfronthosting.co.za>
Message-ID: <1579104817.63.0.761404898879.issue35058@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
Removed message: https://bugs.python.org/msg354421

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35058>
_______________________________________

From report at bugs.python.org  Wed Jan 15 11:23:09 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jan 2020 16:23:09 +0000
Subject: [issue39343] Travis CI: documentation job fails in
 library/nntplib.rst with random network issue on news.gmane.io
In-Reply-To: <1579083774.85.0.947952738007.issue39343@roundup.psfhosted.org>
Message-ID: <1579105389.13.0.972715591689.issue39343@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

FYI, gmane.io is down for a server move today.  It should be back in service by 2100 GMT.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39343>
_______________________________________

From report at bugs.python.org  Wed Jan 15 11:24:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 16:24:08 +0000
Subject: [issue39343] Travis CI: documentation job fails in
 library/nntplib.rst with random network issue on news.gmane.io
In-Reply-To: <1579083774.85.0.947952738007.issue39343@roundup.psfhosted.org>
Message-ID: <1579105448.46.0.606253751329.issue39343@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> FYI, gmane.io is down for a server move today.  It should be back in service by 2100 GMT.

I propose to do nothing and wait. Travis CI is not currently preventing to merge a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39343>
_______________________________________

From report at bugs.python.org  Wed Jan 15 11:25:44 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 15 Jan 2020 16:25:44 +0000
Subject: [issue39343] Travis CI: documentation job fails in
 library/nntplib.rst with random network issue on news.gmane.io
In-Reply-To: <1579083774.85.0.947952738007.issue39343@roundup.psfhosted.org>
Message-ID: <1579105544.49.0.602971437232.issue39343@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I should have checked first.  The move was completed ahead of schedule and it's now back in service.  The tests should no loner fail.

https://lars.ingebrigtsen.no/2020/01/15/news-gmane-org-is-now-news-gmane-io/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39343>
_______________________________________

From report at bugs.python.org  Wed Jan 15 11:32:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 16:32:55 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1579105975.54.0.508868374175.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ed154c387efc5f978ec97900ec9e0ec6631d5498 by Victor Stinner (Hai Shi) in branch 'master':
bpo-1635741: Port _json extension module to multiphase initialization (PEP 489) (GH-17835)
https://github.com/python/cpython/commit/ed154c387efc5f978ec97900ec9e0ec6631d5498


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Wed Jan 15 11:38:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 16:38:59 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1579106339.2.0.810134864582.issue38630@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e85a305503bf83c5a8ffb3a988dfe7b67461cbee by Victor Stinner in branch 'master':
bpo-38630: Fix subprocess.Popen.send_signal() race condition (GH-16984)
https://github.com/python/cpython/commit/e85a305503bf83c5a8ffb3a988dfe7b67461cbee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Wed Jan 15 11:53:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 16:53:35 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1579107215.22.0.0479704863958.issue38630@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

While there was no strong agreement on my change, Nathaniel and Giampaolo said that it should not harm to merge it :-) So I merged my change.

It has been said multiple times: my change doesn't fully close the race condition. It only reduces the risk that it happens. I rephrased my change to mention that there is still room for the race condition and that polling only *reduces* the risk, it doesn't fully fix the race condition.

--

Changing locking can help. But I'm not sure that it covers *all* cases. For example, what if another function calls os.waitpid() directly for whatever reason and the process completed? The pid recycling issue can also happen in this case, no?

Linux pidfd really fix the issue. If someone wants to enhance subprocess to use the new os.pidfd_open(), I suggest to open a separated issue.

Another approach is to emulate pidfd in userspace. Giampaolo explains that he also compares the process creation time for that (msg356571). I'm not excited to workaround OS issue this way. It requires to write platform specific get_create_time() code. I would prefer to reuse what the OS provides when available: Linux pidfd.

--

This issue title is quite explicit on purpose: "subprocess.Popen.send_signal() should poll the process". I now close this issue: send_signal() does now poll :-)

Because there is no *strong* consensus on my change, I decided to not backport it to stable branches 3.7 and 3.8.

Thanks everyone for this very interesting discussion!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38630>
_______________________________________

From report at bugs.python.org  Wed Jan 15 12:15:10 2020
From: report at bugs.python.org (Luciana)
Date: Wed, 15 Jan 2020 17:15:10 +0000
Subject: [issue39305] Merge nntplib._NNTPBase and nntplib.NNTP
In-Reply-To: <1578757948.77.0.383613154988.issue39305@roundup.psfhosted.org>
Message-ID: <1579108510.55.0.308973018479.issue39305@roundup.psfhosted.org>


Luciana <lucianadacostamarques at gmail.com> added the comment:

Thank you, I am creating the patch now and will submit it later today!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39305>
_______________________________________

From report at bugs.python.org  Wed Jan 15 12:26:12 2020
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Wed, 15 Jan 2020 17:26:12 +0000
Subject: [issue38593] Python 3.7 does not catch infinite recursion for some
 values of sys.getrecursionlimit()
In-Reply-To: <1572040268.11.0.31838216135.issue38593@roundup.psfhosted.org>
Message-ID: <1579109172.78.0.223531385433.issue38593@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

The stack is fairly deep here, and I didn't have time to filter out the smallest repro. 

Since this check is best effort, and not reproducible on the 3.8, perhaps this is a low-priority issue.

Thanks.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38593>
_______________________________________

From report at bugs.python.org  Wed Jan 15 12:28:51 2020
From: report at bugs.python.org (Valentyn Tymofieiev)
Date: Wed, 15 Jan 2020 17:28:51 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1579109331.41.0.0448275509175.issue38884@roundup.psfhosted.org>


Valentyn Tymofieiev <valentyn at google.com> added the comment:

Just checking - is issue38884.zip an acceptable repro for this issue?
Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Wed Jan 15 12:46:37 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 15 Jan 2020 17:46:37 +0000
Subject: [issue38361] syslog: Default "ident" in syslog.openlog() shouldn't
 contain slash
In-Reply-To: <1570102738.99.0.163183464343.issue38361@roundup.psfhosted.org>
Message-ID: <1579110397.28.0.227469372707.issue38361@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
components: +Library (Lib) -Extension Modules
nosy: +brandtbucher
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38361>
_______________________________________

From report at bugs.python.org  Wed Jan 15 13:44:24 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 15 Jan 2020 18:44:24 +0000
Subject: [issue38884] __import__ is not thread-safe on Python 3
In-Reply-To: <1574363514.58.0.324753075286.issue38884@roundup.psfhosted.org>
Message-ID: <1579113864.39.0.638210008416.issue38884@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@valentyn just assume it's good enough unless some asks otherwise. People are probably too busy right now to be looking at this and so you might be waiting a while for a more definitive answer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38884>
_______________________________________

From report at bugs.python.org  Wed Jan 15 13:55:56 2020
From: report at bugs.python.org (Darren Hamilton)
Date: Wed, 15 Jan 2020 18:55:56 +0000
Subject: [issue39345] Py_Initialize Hangs on Windows 10
Message-ID: <1579114556.26.0.996943969176.issue39345@roundup.psfhosted.org>


New submission from Darren Hamilton <d.hamilton at procept-biorobotics.com>:

This is related to https://bugs.python.org/issue17797, which is closed.

Using Python 3.7.4, Windows 10.0.18362, Visual Studio 2017 and running as a C Application.  Py_Initialize() eventually calls is_valid_fd with STDIN.  The behavior appears to cause both dup() and fstat() to hang indefinitely (using RELEASE MSVCRT DLLs, it works correctly using MSVCRT Debug DLLs).  The call stack shows Windows is waiting for some Windows Event.  The recommended patch in issue17797 will not work.

is_valid_fd appears to want to read the 'input' using a file descriptor.  since both dup and fstat hang, I realized that isatty() would indicate if the file descriptor is valid and works for any predefined FD descriptor(STDIN-0, STDOUT-1, STDERR-2).

#if defined(MS_WINDOWS)
	struct stat buf;
	if (fd >= fileno(stdin) && fd <= fileno(stderr)) {
		return (_isatty(fd) == 0 && errno == EBADF) ? 0 : 1;
	}
	else if (fstat(fd, &buf) < 0 && (errno == EBADF || errno == ENOENT))
		return 0;
	return 1;
#else

----------
components: Library (Lib), Windows
messages: 360070
nosy: dhamilton, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Py_Initialize Hangs on Windows 10
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39345>
_______________________________________

From report at bugs.python.org  Wed Jan 15 14:16:33 2020
From: report at bugs.python.org (Carlton Gibson)
Date: Wed, 15 Jan 2020 19:16:33 +0000
Subject: [issue37373] Configuration of windows event loop for libraries
In-Reply-To: <1561228405.39.0.674272094682.issue37373@roundup.psfhosted.org>
Message-ID: <1579115793.3.0.60226198582.issue37373@roundup.psfhosted.org>


Change by Carlton Gibson <carlton.gibson at noumenal.es>:


----------
nosy: +carltongibson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37373>
_______________________________________

From report at bugs.python.org  Wed Jan 15 14:58:22 2020
From: report at bugs.python.org (Paul Ollis)
Date: Wed, 15 Jan 2020 19:58:22 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1579118302.65.0.470463967541.issue39318@roundup.psfhosted.org>


Paul Ollis <python at ollis.me.uk> added the comment:

I think it is worth pointing out that the semantics of 

    f = ``open(fd, closefd=True)`` 

are broken (IMHO) because an exception can result in an unreferenced file
object that has taken over reponsibility for closing the fd, but it can
also fail without creating the file object.

Therefore it should be considered a bad idea to use open in this way. So
NamedTemporaryFile should take responsibility for closing the fd; i.e. it
should used closefd=False.

I would suggest that NamedTemporaryFile's code should be:

    try:
        file = _io.open(fd, mode, buffering=buffering, closefd=False,
                        newline=newline, encoding=encoding, errors=errors)
        return _TemporaryFileWrapper(file, name, delete)
    except BaseException:
        _os.close(fd)
        try:
            _os.unlink(name)
        except OSError:
            pass  # On windows the file will already be deleted.
        raise

And '_os.close(self.file.fileno())' should be added after each of the two calls
to 'self.file.close()' in _TemporaryFileCloser.

Some notes on the design choices here.

1. The exception handling performs the close *before* the unlink because:

   - That is the normal order that people expect.
   - It is most important that the file is closed. We cannot rule out the 
     possibility of the unlink raising an exception, which could leak the fd.

2. BaseException is caught because we should not leak a file descriptor for
   KeyboardInterrupt or any other exception.

3. It is generally good practice to protect os.unlink with a try ... except
   OSError. So I think this is an appropriate way to prevent the Windows
   specific error. 

   It will also suppress some other, rare but possible, errors. I think that
   this is legitimate behaviour, but it should be documented.

----------
nosy: +paul_ollis

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Wed Jan 15 15:27:38 2020
From: report at bugs.python.org (Drew DeVault)
Date: Wed, 15 Jan 2020 20:27:38 +0000
Subject: [issue39346] gzip module only supports half of possible read/write
 scenarios
Message-ID: <1579120058.89.0.688292733504.issue39346@roundup.psfhosted.org>


New submission from Drew DeVault <sir at cmpwn.com>:

A gzip file can have uncompressed data written to it, writing compressed data to the underlying file. It can also have uncompressed data read from it, reading compressed data from the underlying file.

However, it does not support reading compressed data from an underlying uncompressed file, nor writing compressed data to an underlying uncompressed file.

This makes it impossible to, for example, obtain an arbitrary file-like object and produce another file-like object which transparently compresses data read from the first.

----------
components: Library (Lib)
messages: 360072
nosy: ddevault
priority: normal
severity: normal
status: open
title: gzip module only supports half of possible read/write scenarios
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39346>
_______________________________________

From report at bugs.python.org  Wed Jan 15 15:27:46 2020
From: report at bugs.python.org (Drew DeVault)
Date: Wed, 15 Jan 2020 20:27:46 +0000
Subject: [issue39346] gzip module only supports half of possible read/write
 scenarios
In-Reply-To: <1579120058.89.0.688292733504.issue39346@roundup.psfhosted.org>
Message-ID: <1579120066.94.0.0223909862909.issue39346@roundup.psfhosted.org>


Change by Drew DeVault <sir at cmpwn.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39346>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:03:38 2020
From: report at bugs.python.org (Sebastian Berg)
Date: Wed, 15 Jan 2020 21:03:38 +0000
Subject: [issue39347] Use of argument clinic like parsing and `METH_FASTCALL`
 support in extension modules
Message-ID: <1579122218.66.0.0534330814443.issue39347@roundup.psfhosted.org>


New submission from Sebastian Berg <sebastian at sipsolutions.net>:

This is mainly an information request, so sorry if its a bit besides the point (I do not mind if you just close it). But it seemed a bit too specific to get answers in most places...
In Python you use argument clinic, which supports `METH_FASTCALL`, that seems pretty awesome.

For extension modules, I am not sure that argument clinic is a straight forward choice, since it probably generates code specific to a single Python version and also using, while we need to support multiple versions (including versions that do not support `METH_FASTCALL`.

So the question would be if there is some idea for providing such C-API, or for example exposing `_PyArg_UnpackKeywords` (which is at the heart of kwarg parsing).

My use-case is that some NumPy functions do have a nice speedup when using `METH_FASTCALL` and better argument clinic style faster arg-parsing. Which is why, looking at these things, I practically reimplemented a slightly dumbed down version of `PyArg_ParseTupleAndKeywords` working much like argument clinic (except less smart and only using macros and no code generation).

That seems viable, but also feels a bit wrong, so I am curious if there may be a better solution or whether it would be plausible to expose `_PyArg_UnpackKeywords` to reduce code duplication. (although I suppose due to old python version support that would effectively take years)

For completeness, my code in question is here: https://github.com/numpy/numpy/pull/15269 with the actual usage pattern being:

static PyObject *my_method(PyObject *self, NPY_ARGUMENTS_DEF)
{
    NPY_PREPARE_ARGPARSER;
    PyObject *argument1;
    int argument2 = -1;
    if (!npy_parse_arguments("method", 1, -1, NPY_ARGUMENTS_PASS),
                "argument1", NULL, &argument1,
                "argument2", &PyArray_PythonPyIntFromInt, &argument2,
                NULL, NULL, NULL) {
        return NULL;
    }
}

----------
components: Argument Clinic
messages: 360073
nosy: larry, seberg
priority: normal
severity: normal
status: open
title: Use of argument clinic like parsing and `METH_FASTCALL` support in extension modules
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39347>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:11:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 15 Jan 2020 21:11:47 +0000
Subject: [issue39344] Getting error while importing ssl " import _ssl # if we
 can't import it,
 let the error propagate ImportError: DLL load failed while importing _ssl: The
 specified module could not be found."
In-Reply-To: <1579095353.91.0.817394645763.issue39344@roundup.psfhosted.org>
Message-ID: <1579122707.33.0.750201783675.issue39344@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

More precisely, make sure the libcrypto-1_1.dll and libssl-1_1.dll files are in the same directory as your _ssl.pyd, but _not_ inside your Python38.zip file (zip import does not support native modules, they have to be outside of the zip).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39344>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:27:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:27:53 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1579123672.99.0.505666638321.issue35943@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The changes required to successfully do this backport are many and affect critical areas. I am not in a hurry to do this. If anyone else wants to take this up quickly, please do.

Do you mean that there is a risk that the backport introduces a regression in another part of the code? If yes, I would suggest to not backport the change to *stable* branches.

People survived with bug. Do you really *have to* backport the fix?

Note: this issue is closed. If you consider to backport it, I suggest to reopen the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:29:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:29:37 +0000
Subject: [issue35665] Function ssl.create_default_context raises exception on
 Windows 10 when called with ssl.Purpose.SERVER_AUTH) attribute
In-Reply-To: <1546691085.37.0.66333867377.issue35665@roundup.psfhosted.org>
Message-ID: <1579123777.39.0.137243928957.issue35665@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35665>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:31:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:31:33 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1579123893.52.0.0334241855218.issue37224@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:32:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:32:47 +0000
Subject: [issue24416] Have date.isocalendar() return a structseq instance
In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za>
Message-ID: <1579123967.8.0.951452047155.issue24416@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24416>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:33:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:33:36 +0000
Subject: [issue19083] IDNA prefix should be case insensitive
In-Reply-To: <1380036051.22.0.99632321977.issue19083@psf.upfronthosting.co.za>
Message-ID: <1579124015.99.0.721622532324.issue19083@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19083>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:37:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:37:57 +0000
Subject: [issue36746] Create test for fcntl.lockf()
In-Reply-To: <1556476378.45.0.872717637619.issue36746@roundup.psfhosted.org>
Message-ID: <1579124277.71.0.379918132873.issue36746@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

PR #17010 of bpo-22367 added tests for fcntl.lockf(). I close this PR as a duplicate of bpo-22367. Thanks @nanjekyejoannah anyway!

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Add open_file_descriptor parameter to fcntl.lockf() (use the new F_OFD_SETLK flag)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36746>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:38:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:38:34 +0000
Subject: [issue39123] PyThread_xxx() not available when using limited API
In-Reply-To: <1577111024.93.0.368390768924.issue39123@roundup.psfhosted.org>
Message-ID: <1579124314.16.0.0499844644473.issue39123@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39123>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:40:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:40:05 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1579124405.93.0.459164346598.issue39274@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Does someone want to propose a PR to modify fractions.Fraction.__bool__() to use "return bool(a._numerator)"?

----------
keywords: +newcomer friendly
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39274>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:45:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:45:42 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579124742.94.0.141189163255.issue32615@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I modified ceval.c to accept dict subclasses when I was working on PEP 416:
https://www.python.org/dev/peps/pep-0416/

This PEP motivation was to implement a sandbox. The PEP was rejected. Later, I closed my pysandbox beause it was "broken by design":
https://lwn.net/Articles/574215/

Paul Sokolovsky wrote in bpo-36220 than his idea is also to implement a sandbox:
https://bugs.python.org/issue36220#msg359046

IMHO we should reject dict subclasses to make Python (especially ceval.c) more efficient. The global type must be checked at every place where it's possible to specify or override globals. Like the exec() function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:47:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:47:31 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1579124851.84.0.199996555926.issue35561@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Thank you, Victor, for the comments.  I will update PR 17782.

Since it's a very different approach (modify C vs suppress the false alarm), I suggest instead to open a new different PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35561>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:49:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:49:57 +0000
Subject: [issue36048] Deprecate implicit truncating when convert Python
 numbers to C integers: use __index__, not __int__
In-Reply-To: <1550644985.32.0.26417547244.issue36048@roundup.psfhosted.org>
Message-ID: <1579124997.13.0.976026235902.issue36048@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Serhiy: any thoughts about what version should be targeted for eventual removal of the functionality deprecated in this PR? 3.10?

IMHO it should be done at the *very beginning* of a release cycle. Python 3.9.0 alpha 1 *and* alpha 2 versions have already been released. It's too late for the 3.9 cycle.

I'm fine with 3.10.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36048>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:52:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:52:16 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1579125136.66.0.297884737807.issue39200@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> 3rd party: IMHO, if somebody relies on the error message, not error type, I think that the code pattern is bad usage

I don't think that we can be pedantic on how projects should be tested.

IMHO it's too risky. I rejected backports. The risk of regression in a *minor* release is just too high. Such "cleanup" change is better fitted for a new 3.x major release.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39200>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:54:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:54:41 +0000
Subject: [issue39010] ProactorEventLoop raises unhandled ConnectionResetError
In-Reply-To: <1575924458.67.0.403977169674.issue39010@roundup.psfhosted.org>
Message-ID: <1579125281.66.0.202521872256.issue39010@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39010>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:54:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:54:55 +0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple
 api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1579125295.67.0.642706870041.issue1820@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1820>
_______________________________________

From report at bugs.python.org  Wed Jan 15 16:55:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 15 Jan 2020 21:55:07 +0000
Subject: [issue14014] codecs.StreamWriter.reset contract not fulfilled
In-Reply-To: <1329242513.77.0.581823861095.issue14014@psf.upfronthosting.co.za>
Message-ID: <1579125307.32.0.298382434002.issue14014@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14014>
_______________________________________

From report at bugs.python.org  Wed Jan 15 17:40:00 2020
From: report at bugs.python.org (rekcartgubnohtyp)
Date: Wed, 15 Jan 2020 22:40:00 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1579128000.55.0.216373648381.issue39318@roundup.psfhosted.org>


Change by rekcartgubnohtyp <nader at mail.glory.co.jp>:


----------
nosy: +rekcartgubnohtyp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Wed Jan 15 17:47:23 2020
From: report at bugs.python.org (Sebastian Berg)
Date: Wed, 15 Jan 2020 22:47:23 +0000
Subject: [issue39274] Conversion from fractions.Fraction to bool
In-Reply-To: <1578573831.64.0.0454191861618.issue39274@roundup.psfhosted.org>
Message-ID: <1579128443.67.0.153804710176.issue39274@roundup.psfhosted.org>


Change by Sebastian Berg <sebastian at sipsolutions.net>:


----------
keywords: +patch
pull_requests: +17412
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18017

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39274>
_______________________________________

From report at bugs.python.org  Wed Jan 15 17:50:31 2020
From: report at bugs.python.org (Tim Peters)
Date: Wed, 15 Jan 2020 22:50:31 +0000
Subject: [issue39310] Add math.ulp(x): unit in the last place
In-Reply-To: <1578832414.46.0.631511260032.issue39310@roundup.psfhosted.org>
Message-ID: <1579128631.25.0.487977735566.issue39310@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

`ulp()` is the right name:  universally understood by those who know how to use it, and easy to find exhaustive web explanations for those who don't.

In a different context, spelling out some variant of Hypertext_Transfer_Protocol would be as wrong-headed to avoid the "cryptic" http.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39310>
_______________________________________

From report at bugs.python.org  Wed Jan 15 17:52:01 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jan 2020 22:52:01 +0000
Subject: [issue37958] Adding get_profile_dict to pstats
In-Reply-To: <1566877978.54.0.497370622216.issue37958@roundup.psfhosted.org>
Message-ID: <1579128721.15.0.774305441586.issue37958@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 01602ae40321ecdb375ee6d44eaeac3255857879 by Miss Islington (bot) (Daniel Olshansky) in branch 'master':
bpo-37958: Adding get_profile_dict to pstats (GH-15495)
https://github.com/python/cpython/commit/01602ae40321ecdb375ee6d44eaeac3255857879


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37958>
_______________________________________

From report at bugs.python.org  Wed Jan 15 17:54:13 2020
From: report at bugs.python.org (Albert Zeyer)
Date: Wed, 15 Jan 2020 22:54:13 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1579128853.88.0.08641495546.issue39318@roundup.psfhosted.org>


Albert Zeyer <albzey at googlemail.com> added the comment:

> I think it is worth pointing out that the semantics of 
>
>     f = ``open(fd, closefd=True)`` 
>
> are broken (IMHO) because an exception can result in an unreferenced file
> object that has taken over reponsibility for closing the fd, but it can
> also fail without creating the file object.

I thought that if this raises a (normal) exception, it always means that it did not have overtaken the `fd`, i.e. never results in an unreferenced file object which has taken ownership of `fd`.

It this is not true right now, you are right that this is problematic. But this should be simple to fix on the CPython side, right? I.e. to make sure whenever some exception is raised here, even if some temporary file object already was constructed, it will not close `fd`. It should be consistent in this behavior, otherwise indeed, the semantics are broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Wed Jan 15 17:59:29 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 15 Jan 2020 22:59:29 +0000
Subject: [issue37958] Adding get_profile_dict to pstats
In-Reply-To: <1566877978.54.0.497370622216.issue37958@roundup.psfhosted.org>
Message-ID: <1579129169.82.0.0347234651898.issue37958@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks Daniel!

----------
nosy: +gregory.p.smith
resolution:  -> fixed
stage:  -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37958>
_______________________________________

From report at bugs.python.org  Wed Jan 15 18:41:24 2020
From: report at bugs.python.org (Oz Tiram)
Date: Wed, 15 Jan 2020 23:41:24 +0000
Subject: [issue39348] wrong rst syntax in socket.rst
Message-ID: <1579131684.91.0.584754331907.issue39348@roundup.psfhosted.org>


New submission from Oz Tiram <nahumoz at gmail.com>:

The code block for the isn't hightlighted:



Changed in version 3.7: When SOCK_NONBLOCK or SOCK_CLOEXEC bit flags are applied to type they are cleared, and socket.type will not reflect them. They are still passed to the underlying system socket() call. Therefore::

    sock = socket.socket(

...

This is because the double colon is directly after the word Therefore.


This fix is very simple:

       :attr:`socket.type` will not reflect them.  They are still passed
-      to the underlying system `socket()` call.  Therefore::
+      to the underlying system `socket()` call.  Therefore,
+
+      ::
 
           sock = socket.socket(
               socket.AF_INET,
       ...


I have prepared a PR for this.

----------
assignee: docs at python
components: Documentation
messages: 360086
nosy: Oz.Tiram, docs at python
priority: normal
severity: normal
status: open
title: wrong rst syntax in socket.rst
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39348>
_______________________________________

From report at bugs.python.org  Wed Jan 15 18:43:22 2020
From: report at bugs.python.org (Oz Tiram)
Date: Wed, 15 Jan 2020 23:43:22 +0000
Subject: [issue39348] wrong rst syntax in socket.rst
In-Reply-To: <1579131684.91.0.584754331907.issue39348@roundup.psfhosted.org>
Message-ID: <1579131802.63.0.418853286419.issue39348@roundup.psfhosted.org>


Change by Oz Tiram <nahumoz at gmail.com>:


----------
keywords: +patch
pull_requests: +17413
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18018

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39348>
_______________________________________

From report at bugs.python.org  Wed Jan 15 18:55:18 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jan 2020 23:55:18 +0000
Subject: [issue39348] wrong rst syntax in socket.rst
In-Reply-To: <1579131684.91.0.584754331907.issue39348@roundup.psfhosted.org>
Message-ID: <1579132518.09.0.358079532937.issue39348@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fad8b5674c66d9e00bb788e30adddb0c256c787b by Miss Islington (bot) (Oz N Tiram) in branch 'master':
bpo-39348: Fix code highlight for the SOCK_NONBLOCK example (GH-18018)
https://github.com/python/cpython/commit/fad8b5674c66d9e00bb788e30adddb0c256c787b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39348>
_______________________________________

From report at bugs.python.org  Wed Jan 15 18:55:26 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jan 2020 23:55:26 +0000
Subject: [issue39348] wrong rst syntax in socket.rst
In-Reply-To: <1579131684.91.0.584754331907.issue39348@roundup.psfhosted.org>
Message-ID: <1579132526.03.0.115772748889.issue39348@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17414
pull_request: https://github.com/python/cpython/pull/18019

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39348>
_______________________________________

From report at bugs.python.org  Wed Jan 15 18:55:34 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 15 Jan 2020 23:55:34 +0000
Subject: [issue39348] wrong rst syntax in socket.rst
In-Reply-To: <1579131684.91.0.584754331907.issue39348@roundup.psfhosted.org>
Message-ID: <1579132534.1.0.341880443947.issue39348@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17415
pull_request: https://github.com/python/cpython/pull/18020

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39348>
_______________________________________

From report at bugs.python.org  Wed Jan 15 18:56:55 2020
From: report at bugs.python.org (Mariatta)
Date: Wed, 15 Jan 2020 23:56:55 +0000
Subject: [issue39348] wrong rst syntax in socket.rst
In-Reply-To: <1579131684.91.0.584754331907.issue39348@roundup.psfhosted.org>
Message-ID: <1579132615.78.0.133970472186.issue39348@roundup.psfhosted.org>


Change by Mariatta <mariatta at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39348>
_______________________________________

From report at bugs.python.org  Wed Jan 15 18:57:06 2020
From: report at bugs.python.org (Mariatta)
Date: Wed, 15 Jan 2020 23:57:06 +0000
Subject: [issue39348] wrong rst syntax in socket.rst
In-Reply-To: <1579131684.91.0.584754331907.issue39348@roundup.psfhosted.org>
Message-ID: <1579132626.01.0.846745610272.issue39348@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

Thanks!

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39348>
_______________________________________

From report at bugs.python.org  Wed Jan 15 19:00:39 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Jan 2020 00:00:39 +0000
Subject: [issue39348] wrong rst syntax in socket.rst
In-Reply-To: <1579131684.91.0.584754331907.issue39348@roundup.psfhosted.org>
Message-ID: <1579132839.49.0.763871154761.issue39348@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 970188c2d792133e2273924a987e0542659a676f by Miss Islington (bot) in branch '3.7':
bpo-39348: Fix code highlight for the SOCK_NONBLOCK example (GH-18018)
https://github.com/python/cpython/commit/970188c2d792133e2273924a987e0542659a676f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39348>
_______________________________________

From report at bugs.python.org  Wed Jan 15 19:01:08 2020
From: report at bugs.python.org (ppperry)
Date: Thu, 16 Jan 2020 00:01:08 +0000
Subject: [issue39344] ImportError: DLL load failed while importing _ssl: The
 specified module could not be found."
In-Reply-To: <1579095353.91.0.817394645763.issue39344@roundup.psfhosted.org>
Message-ID: <1579132868.62.0.460309915199.issue39344@roundup.psfhosted.org>


Change by ppperry <mapreader at olum.org>:


----------
title: Getting error while importing ssl " import _ssl             # if we can't import it, let the error propagate ImportError: DLL load failed while importing _ssl: The specified module could not be found." -> ImportError: DLL load failed while importing _ssl: The specified module could not be found."

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39344>
_______________________________________

From report at bugs.python.org  Wed Jan 15 19:01:28 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 16 Jan 2020 00:01:28 +0000
Subject: [issue39348] wrong rst syntax in socket.rst
In-Reply-To: <1579131684.91.0.584754331907.issue39348@roundup.psfhosted.org>
Message-ID: <1579132888.06.0.467247734116.issue39348@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 19bd3a18626b504dc92abb44019cad600c7ef221 by Miss Islington (bot) in branch '3.8':
bpo-39348: Fix code highlight for the SOCK_NONBLOCK example (GH-18018)
https://github.com/python/cpython/commit/19bd3a18626b504dc92abb44019cad600c7ef221


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39348>
_______________________________________

From report at bugs.python.org  Wed Jan 15 19:48:35 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 16 Jan 2020 00:48:35 +0000
Subject: [issue39200] Fix inaccurate TypeError messages when calling with
 insufficient arguments
In-Reply-To: <1578061671.15.0.421279192127.issue39200@roundup.psfhosted.org>
Message-ID: <1579135715.46.0.292477797737.issue39200@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Thanks for the opinion.
Sounds reasonable!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39200>
_______________________________________

From report at bugs.python.org  Wed Jan 15 20:27:02 2020
From: report at bugs.python.org (David Lambert)
Date: Thu, 16 Jan 2020 01:27:02 +0000
Subject: [issue38649] tkinter messagebox is sloppy
In-Reply-To: <1572542092.42.0.770202652778.issue38649@roundup.psfhosted.org>
Message-ID: <4721b9c2-a4c1-5f9f-5cf1-3d1b77d785a4@gmail.com>


David Lambert <b49p23tivg at gmail.com> added the comment:

Sometimes I say nice things about python.

https://www.quora.com/Is-Python-fast-yet/answer/David-Lambert-86?__nsrc__=4&__snid3__=6376944631

On 10/31/19 1:14 PM, Brett Cannon wrote:
> Brett Cannon <brett at python.org> added the comment:
>
> Please note that calling something "sloppy" and that somehow its development was done in some "carelessness" fashion to the point of being "egregious" is not motivating to others to try and help. Trying to support all of this code for free in one's spare time is not easy, so I would ask you try to be more understanding and nicer in your comments.
>
> ----------
> nosy: +brett.cannon
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue38649>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38649>
_______________________________________

From report at bugs.python.org  Wed Jan 15 23:08:34 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 16 Jan 2020 04:08:34 +0000
Subject: [issue39349] Add "cancel" parameter to
 concurrent.futures.Executor.shutdown()
Message-ID: <1579147714.25.0.252393666546.issue39349@roundup.psfhosted.org>


New submission from Kyle Stanley <aeros167 at gmail.com>:

This feature enhancement issue is based on the following python-ideas thread: https://mail.python.org/archives/list/python-ideas at python.org/thread/ZSUIFN5GTDO56H6LLOPXOLQK7EQQZJHJ/

In summary, the main suggestion was to implement a new parameter called "cancel" (some bikeshedding over the name is welcome, I was thinking "cancel_futures" might be another option) for Executor.shutdown(), that would be added to both ThreadPoolExecutor and ProcessPoolExecutor. When set to True, this parameter would cancel all pending futures that were scheduled to the executor just after setting self._shutdown.

In order to build some experience in working with the internals of the executors (particularly for implementing native pools in asyncio in the future), I plan on working on this issue; assuming Antoine and/or Brian are +1 on it. Guido seemed to approve of the idea.

The implementation in ThreadPoolExecutor should be fairly straightforward, as it would use much of the same logic that's in the private method _initializer_failed() (https://github.com/python/cpython/blob/fad8b5674c66d9e00bb788e30adddb0c256c787b/Lib/concurrent/futures/thread.py#L205-L216). Minus the setting of self._broken, and cancelling each of the work_items (pending futures) instead of setting the BrokenThreadPool exception.

For ProcessPoolExecutor, I'll likely have to spend some more time looking into the implementation details of it to figure out how the cancellation will work. IIUC, it would involve adding some additional logic in _queue_management_worker(), the function which is used by the queue management thread to communicate between the main process and the worker processes spawned by ProcessPoolExecutor.

Specifically, in the "if shutting_down()" block (https://github.com/python/cpython/blob/fad8b5674c66d9e00bb788e30adddb0c256c787b/Lib/concurrent/futures/process.py#L432-L446), I think we could add an additional conditional check to see if self._cancel_pending_work_items is true (new internal flag set during executor.shutdown() if *cancel* is true, just after setting "self._shutdown_thread = True"). In this block, it would iterate through the pending work items, and cancel their associated future. Here's a rough example of what I have in mind:

```
        if shutting_down():
            try:
                # Flag the executor as shutting down as early as possible if it
                # is not gc-ed yet.
                if executor is not None:
                    executor._shutdown_thread = True
+                  if executor._cancel_pending_work_items:
+                      # We only care about the values in the dict, which are
+                      # the actual work items.
+                      for work_item in pending_work_items.values():
+                          work_item.future.cancel()
                # Since no new work items can be added, it is safe to shutdown
                # this thread if there are no pending work items.
                if not pending_work_items:
                    shutdown_worker()
                    return
            except Full:
                # This is not a problem: we will eventually be woken up (in
                # result_queue.get()) and be able to send a sentinel again.
                pass
```

Would something along the lines of the above be a potentially viable method of implementing the *cancel* parameter for ProcessPoolExecutor.shutdown()? The main downside to this implementation is that it can't cancel anything that is already running (pushed from pending_work_items to call_queue). But from my understanding, there isn't a viable means of cancelling anything in the call queue; at that point it's too late.

Anyways, I'll work on the ThreadPoolExecutor implementation in the meantime. As mentioned previously, that one should be more straightforward. After getting it working, I'll open a PR for just ThreadPoolExecutor, and then work on ProcessPoolExecutor in another PR after receiving some feedback on the above idea.

----------
assignee: aeros
messages: 360093
nosy: aeros, bquinlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Add "cancel" parameter to concurrent.futures.Executor.shutdown()
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39349>
_______________________________________

From report at bugs.python.org  Thu Jan 16 01:08:03 2020
From: report at bugs.python.org (Ajaya)
Date: Thu, 16 Jan 2020 06:08:03 +0000
Subject: [issue39344] Getting error while importing ssl " import _ssl # if we
 can't import it,
 let the error propagate ImportError: DLL load failed while importing _ssl: The
 specified module could not be found."
In-Reply-To: <1579122707.33.0.750201783675.issue39344@roundup.psfhosted.org>
Message-ID: <CAONRpOSyE0ZKuc8toQSXRmeKYYB-tnP8=gg2tajVL+GCBLNaWQ@mail.gmail.com>


Ajaya <ajayakumars265 at gmail.com> added the comment:

Thanks all for your quick response. That issue has been resolved by
solution given by  Steve Dower and  Christian Heimes

On Thu, Jan 16, 2020 at 2:41 AM Steve Dower <report at bugs.python.org> wrote:

>
> Steve Dower <steve.dower at python.org> added the comment:
>
> More precisely, make sure the libcrypto-1_1.dll and libssl-1_1.dll files
> are in the same directory as your _ssl.pyd, but _not_ inside your
> Python38.zip file (zip import does not support native modules, they have to
> be outside of the zip).
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39344>
> _______________________________________
>

-- 
Regards:
Ajaya Kumar Sutar
Product Engineer
Siemens Industry Software (India) Private Limited
Tower C, Panchashil Business Park,
Cummins India Office Campus,
Survey No. 21, Balewadi,
Pune, India  411045
Tel: +91-20-39182839(O)
09764180686(P)

----------
title: ImportError: DLL load failed while importing _ssl: The specified module could not be found." -> Getting error while importing ssl " import _ssl # if we can't import it, let the error propagate ImportError: DLL load failed while importing _ssl: The specified module could not be found."

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39344>
_______________________________________

From report at bugs.python.org  Thu Jan 16 03:13:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 08:13:44 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
Message-ID: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

bpo-22486 added math.gcd() and deprecated fractions.gcd() in Python 3.5: commit 48e47aaa28d6dfdae128142ffcbc4b0642422e90.

The function was deprecated during 4 cycles (3.5, 3.6, 3.7, 3.8): I propose attached PR to remove it.

----------
components: Library (Lib)
messages: 360095
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove deprecated fractions.gcd()
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39350>
_______________________________________

From report at bugs.python.org  Thu Jan 16 03:17:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 08:17:24 +0000
Subject: [issue22486] Add math.gcd()
In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za>
Message-ID: <1579162644.03.0.104022747376.issue22486@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17417
pull_request: https://github.com/python/cpython/pull/18021

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22486>
_______________________________________

From report at bugs.python.org  Thu Jan 16 03:17:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 08:17:23 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1579162643.93.0.752397589499.issue39350@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17416
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18021

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39350>
_______________________________________

From report at bugs.python.org  Thu Jan 16 03:25:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 08:25:17 +0000
Subject: [issue39351] Remove base64.encodestring() and base64.decodestring()
 aliases, deprecated since Python 3.1
Message-ID: <1579163117.18.0.498681758214.issue39351@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

base64.encodestring() and base64.decodestring() are aliases deprecated since Python 3.1: encodebytes() and decodebytes() should be used instead.

In Python 3, "string" means Unicode, whereas these functions really work at the bytes level:

>>> base64.encodestring("text")
TypeError: expected bytes-like object, not str

>>> base64.decodestring("text")
TypeError: expected bytes-like object, not str

encodebytes() and decodebytes() names are explicit on the expected types (bytes or bytes-like).

This issue is similar to bpo-38916: "Remove array.fromstring() and array.tostring() aliases, deprecated since Python 3.2".

Attached PR removes the deprecated aliases base64.encodestring() and base64.decodestring().

----------
components: Library (Lib)
messages: 360096
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove base64.encodestring() and base64.decodestring() aliases, deprecated since Python 3.1
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39351>
_______________________________________

From report at bugs.python.org  Thu Jan 16 03:30:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 08:30:48 +0000
Subject: [issue39351] Remove base64.encodestring() and base64.decodestring()
 aliases, deprecated since Python 3.1
In-Reply-To: <1579163117.18.0.498681758214.issue39351@roundup.psfhosted.org>
Message-ID: <1579163448.28.0.575606780331.issue39351@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17418
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18022

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39351>
_______________________________________

From report at bugs.python.org  Thu Jan 16 03:32:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 08:32:40 +0000
Subject: [issue39351] Remove base64.encodestring() and base64.decodestring()
 aliases, deprecated since Python 3.1
In-Reply-To: <1579163117.18.0.498681758214.issue39351@roundup.psfhosted.org>
Message-ID: <1579163560.1.0.0700309931413.issue39351@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The deprecation was introduced 11 years ago in bpo-3613 by this change:

commit b54d801280e3f510782e2855504710947d10f053
Author: Georg Brandl <georg at python.org>
Date:   Thu Jun 4 09:11:51 2009 +0000

    #3613: add base64.encodebytes and decodebytes as the new spelling of encodestring and decodestring; deprecate the latter.

The aliases were deprecated for 7 cycles (Python 3.1 to Python 3.8).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39351>
_______________________________________

From report at bugs.python.org  Thu Jan 16 03:48:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 08:48:01 +0000
Subject: [issue39352] Remove the formatter module, deprecated since Python 3.4
Message-ID: <1579164481.25.0.406270516611.issue39352@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The formatter module has been deprecated in Python 3.4 by bpo-18716: commit 1448ecf470013cee63c0682f615c5256928dc6b0.

In 2014, its removal was scheduled in Python 3.6: commit 29636aeaccaf6a1412e0dc7c230db29cccf68381.

But bpo-25407 cancelled the removal from Python 3.6: commit 5ad5a7d31f5328c73df523b6ade330d88573717e

"The new PEP 4 policy of any module existing in both 2.7 and 3.5 applies here, hence the module will be with us for a bit longer."

In the meanwhile, I'm not aware of anyone opposed to the removal.

Python 2.7 reached it's end of life, so I propose to remove the module:
https://docs.python.org/3.8/library/formatter.html

If someone needs this module, it's a single formatter.py file: it can easily be copied from Python 3.8. The intent here is to reduce the size of the standard library to remove the maintenance burden on Python core developers.

Note: I'm surprised, but it seems like the formatter module has no test!?

Attached PR removes the module.

----------
components: Library (Lib)
messages: 360098
nosy: brett.cannon, vstinner
priority: normal
severity: normal
status: open
title: Remove the formatter module, deprecated since Python 3.4
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39352>
_______________________________________

From report at bugs.python.org  Thu Jan 16 03:53:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 08:53:18 +0000
Subject: [issue39352] Remove the formatter module, deprecated since Python 3.4
In-Reply-To: <1579164481.25.0.406270516611.issue39352@roundup.psfhosted.org>
Message-ID: <1579164798.07.0.860964381088.issue39352@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17419
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18023

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39352>
_______________________________________

From report at bugs.python.org  Thu Jan 16 03:57:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 08:57:15 +0000
Subject: [issue39352] Remove the formatter module, deprecated since Python 3.4
In-Reply-To: <1579164481.25.0.406270516611.issue39352@roundup.psfhosted.org>
Message-ID: <1579165035.74.0.0129864799472.issue39352@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I did a quick & dirty code search in GitHub to check for "import formatter". There is no "import formatter" in the 5 first pages of code search in the Python programming language. IMHO it seems that this module is basically unused. To be honest, I even didn't know that it existed!?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39352>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:14:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 09:14:45 +0000
Subject: [issue39353] Deprecate the binhex module
Message-ID: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The binhex module encodes and decodes Apple Macintosh binhex4 data. It was originally developed for TRS-80. In the 1980s and early 1990s it was used on classic Mac OS 9 to encode binary email attachments.

Mac OS 9 is now heavily outdated, replaced by "macOS" (previously known as "Mac OS X").

I propose to emit a DeprecationWarning in the binhex module and document that it's deprecated.

I don't think that we have to schedule its removal yet, it can be decided later. A first deprecation warning emitted at runtime might help to warn last users, if there is any.

There are two binhex open issues:

* bpo-29566: no activity for almost 2 years (February 2017)
* bpo-34063: no activity for 1 year 1/2 (July 2018)

If we ignore global cleanup (done on the whole Python code base at once, not specific to binhex), the binhex was basically untouched since it has been ported to Python 3 (10 years ago). Maybe it means that it is very stable, which can be seen as a quality ;-)

I looked for "import binhex" in the first 10 pages of GitHub code search (restricted to Python programming language). I mostly found copies of Python test_binhex.py, no real usage of binhex.

On Stackoverflow, the latest questions about binhex has been asked in 2012:
https://stackoverflow.com/questions/12467973/binhex-decoding-using-java-code

I also found an answer suggesting to use binascii.a2b_hex() to decode a string the hexadecimal string "2020202020202020202020205635514d385a5856":
https://stackoverflow.com/questions/9683278/how-to-get-hard-disk-drivers-serial-number-in-python/9683837#9683837

But binascii.unhexlify() does the same than binascii.a2b_hex().

Attached PR deprecates binhex.

----------
components: Library (Lib)
messages: 360100
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Deprecate the binhex module
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:18:12 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 16 Jan 2020 09:18:12 +0000
Subject: [issue39349] Add "cancel" parameter to
 concurrent.futures.Executor.shutdown()
In-Reply-To: <1579147714.25.0.252393666546.issue39349@roundup.psfhosted.org>
Message-ID: <1579166292.17.0.718300663169.issue39349@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39349>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:18:53 2020
From: report at bugs.python.org (bizywizy)
Date: Thu, 16 Jan 2020 09:18:53 +0000
Subject: [issue39354] collections.UserString format and format_map return a
 string
Message-ID: <1579166333.43.0.0162767475956.issue39354@roundup.psfhosted.org>


New submission from bizywizy <bizywiz at gmail.com>:

collections.UserString.format and collections.UserString.format_map return a string instaed of UserString.

This is quite weird because I expect that the %-syntax and `format` method have to produce the same result.

```
>>> isinstance(UserString('Hello %s') % 'World', UserString)
True
>>> isinstance(UserString('Hello {}').format('World'), UserString)
False
```

----------
components: Library (Lib)
messages: 360101
nosy: bizywizy
priority: normal
severity: normal
status: open
title: collections.UserString format and format_map return a string
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/issue39354>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:22:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 09:22:27 +0000
Subject: [issue39353] Deprecate the binhex module
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579166547.66.0.374336917802.issue39353@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17420
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18025

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:24:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 09:24:20 +0000
Subject: [issue39351] Remove base64.encodestring() and base64.decodestring()
 aliases, deprecated since Python 3.1
In-Reply-To: <1579163117.18.0.498681758214.issue39351@roundup.psfhosted.org>
Message-ID: <1579166660.26.0.520576709077.issue39351@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 210c19e3c5b86535a73487fa737752de8eb1d866 by Victor Stinner in branch 'master':
bpo-39351: Remove base64.encodestring() (GH-18022)
https://github.com/python/cpython/commit/210c19e3c5b86535a73487fa737752de8eb1d866


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39351>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:24:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 09:24:34 +0000
Subject: [issue39351] Remove base64.encodestring() and base64.decodestring()
 aliases, deprecated since Python 3.1
In-Reply-To: <1579163117.18.0.498681758214.issue39351@roundup.psfhosted.org>
Message-ID: <1579166674.2.0.62783538786.issue39351@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39351>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:25:21 2020
From: report at bugs.python.org (Keith)
Date: Thu, 16 Jan 2020 09:25:21 +0000
Subject: =?utf-8?q?=5Bissue39355=5D_The_Python_library_will_not_compile_with_a_C++?=
 =?utf-8?q?2020_compiler_because_the_code_uses_the_reserved_=E2=80=9Cmodul?=
 =?utf-8?b?ZeKAnSBrZXl3b3Jk?=
Message-ID: <1579166721.74.0.203064876936.issue39355@roundup.psfhosted.org>


New submission from Keith <keithtangtw at gmail.com>:

The Python library will not compile with a C++2020 compiler because the code uses the reserved ?module? keyword
 
For example, in warnings.h, we have the following code:
 
#ifndef Py_LIMITED_API
PyAPI_FUNC(int) PyErr_WarnExplicitObject(
    PyObject *category,
    PyObject *message,
    PyObject *filename,
    int lineno,
    PyObject *module,
PyObject *registry);
 
 
In modsupport.h we have the following code:
PyAPI_FUNC(int) PyModule_ExecDef(PyObject *module, PyModuleDef *def);
 
We can fix this by using a different identifier, for example ?pyModule? instead of ?module?

----------
components: C API
messages: 360103
nosy: aCuria
priority: normal
severity: normal
status: open
title: The Python library will not compile with a C++2020 compiler because the code uses the reserved ?module? keyword
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39355>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:25:59 2020
From: report at bugs.python.org (bizywizy)
Date: Thu, 16 Jan 2020 09:25:59 +0000
Subject: [issue39354] collections.UserString format and format_map return a
 string
In-Reply-To: <1579166333.43.0.0162767475956.issue39354@roundup.psfhosted.org>
Message-ID: <1579166759.86.0.983408537371.issue39354@roundup.psfhosted.org>


Change by bizywizy <bizywiz at gmail.com>:


----------
keywords: +patch
pull_requests: +17421
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18026

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39354>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:27:07 2020
From: report at bugs.python.org (Paul Ollis)
Date: Thu, 16 Jan 2020 09:27:07 +0000
Subject: [issue39318] NamedTemporaryFile could cause double-close on an fd if
 _TemporaryFileWrapper throws
In-Reply-To: <1578891407.19.0.452054572225.issue39318@roundup.psfhosted.org>
Message-ID: <1579166827.21.0.890495084004.issue39318@roundup.psfhosted.org>


Paul Ollis <python at ollis.me.uk> added the comment:

> I thought that if this raises a (normal) exception, it always means that it
> did not have overtaken the `fd`, i.e. never results in an unreferenced file
> object which has taken ownership of `fd`.

The current CPython implementation does not guard against this happening. Some
incorrect combinations of arguments will definitely cause the problem. It is
also possible that it could occur under other circumstances.

> It this is not true right now, you are right that this is problematic. But
> this should be simple to fix on the CPython side, right? I.e. to make sure
> whenever some exception is raised here, even if some temporary file object
> already was constructed, it will not close `fd`. It should be consistent in
> this behavior, otherwise indeed, the semantics are broken.

I agree. I think it should be fairly simple to fix for CPython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39318>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:30:28 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Jan 2020 09:30:28 +0000
Subject: [issue39353] Deprecate the binhex module
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579167028.08.0.296124222492.issue39353@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

binhex provides an encoding different from binascii.a2b_hex() and binascii.unhexlify().

If deprecate the binhex module, we perhaps should deprecate also binascii.b2a_hqx(), binascii.a2b_hqx(), binascii.rlecode_hqx(), binascii.rledecode_hqx() and binascii.crc_hqx().

But it would be nice to create a separate package on PyPI that provides such functionality before removing it from the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:33:25 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 16 Jan 2020 09:33:25 +0000
Subject: =?utf-8?q?=5Bissue39355=5D_The_Python_library_will_not_compile_with_a_C++?=
 =?utf-8?q?2020_compiler_because_the_code_uses_the_reserved_=E2=80=9Cmodul?=
 =?utf-8?b?ZeKAnSBrZXl3b3Jk?=
In-Reply-To: <1579166721.74.0.203064876936.issue39355@roundup.psfhosted.org>
Message-ID: <1579167205.45.0.583126077813.issue39355@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39355>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:37:16 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Jan 2020 09:37:16 +0000
Subject: =?utf-8?q?=5Bissue39355=5D_The_Python_library_will_not_compile_with_a_C++?=
 =?utf-8?q?2020_compiler_because_the_code_uses_the_reserved_=E2=80=9Cmodul?=
 =?utf-8?b?ZeKAnSBrZXl3b3Jk?=
In-Reply-To: <1579166721.74.0.203064876936.issue39355@roundup.psfhosted.org>
Message-ID: <1579167436.28.0.857078857216.issue39355@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Names of arguments can be just removed from function declarations in header files.

----------
keywords: +easy (C)
nosy: +serhiy.storchaka
stage:  -> needs patch
type:  -> enhancement
versions:  -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39355>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:38:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 09:38:13 +0000
Subject: [issue39356] zipfile suprising "except DeprecationWarning:" block
Message-ID: <1579167493.26.0.213163602183.issue39356@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Lib/zipfile.py contains the following code:

try:
    filename, flag_bits = zinfo._encodeFilenameFlags()
    centdir = struct.pack(structCentralDir,
                          stringCentralDir, create_version,
                          zinfo.create_system, extract_version, zinfo.reserved,
                          flag_bits, zinfo.compress_type, dostime, dosdate,
                          zinfo.CRC, compress_size, file_size,
                          len(filename), len(extra_data), len(zinfo.comment),
                          0, zinfo.internal_attr, zinfo.external_attr,
                          header_offset)
except DeprecationWarning:
    print((structCentralDir, stringCentralDir, create_version,
           zinfo.create_system, extract_version, zinfo.reserved,
           zinfo.flag_bits, zinfo.compress_type, dostime, dosdate,
           zinfo.CRC, compress_size, file_size,
           len(zinfo.filename), len(extra_data), len(zinfo.comment),
           0, zinfo.internal_attr, zinfo.external_attr,
           header_offset), file=sys.stderr)
    raise

It is not considered as good programmating method to put print() statement in production code: usually, it's only used for debugging :-)

The "except DeprecationWarning:" with its print has been added 12 years ago by:

commit bf02e3bb21b2d75cba4ce409a14ae64dbc2dd6d2
Author: Gregory P. Smith <greg at mad-scientist.com>
Date:   Wed Mar 19 03:14:41 2008 +0000

    Fix the struct module DeprecationWarnings that zipfile was triggering by
    removing all use of signed struct values.
    
    test_zipfile and test_zipfile64 pass.  no more warnings.

But I don't recall any complain about a DeprecationWarning on struct.pack() in zipfile.

I propose attached PR to remove it.

----------
components: Library (Lib)
messages: 360107
nosy: vstinner
priority: normal
severity: normal
status: open
title: zipfile suprising "except DeprecationWarning:" block
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39356>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:38:24 2020
From: report at bugs.python.org (Bruce Merry)
Date: Thu, 16 Jan 2020 09:38:24 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1579167503.99.0.378179020242.issue36051@roundup.psfhosted.org>


Bruce Merry <bmerry at gmail.com> added the comment:

I think I've addressed the concerns that were raised in this bug, but let me know if I've missed any.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:41:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 09:41:08 +0000
Subject: [issue39356] zipfile suprising "except DeprecationWarning:" block
In-Reply-To: <1579167493.26.0.213163602183.issue39356@roundup.psfhosted.org>
Message-ID: <1579167668.48.0.77918474347.issue39356@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17423
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18027

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39356>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:43:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 09:43:12 +0000
Subject: [issue39353] Deprecate the binhex module
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579167792.43.0.517817602017.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> But it would be nice to create a separate package on PyPI that provides such functionality before removing it from the stdlib.

This issue is *not* about removing the module :-) Only to mark it as deprecated.

> If deprecate the binhex module, we perhaps should deprecate also binascii.b2a_hqx(), binascii.a2b_hqx(), binascii.rlecode_hqx(), binascii.rledecode_hqx() and binascii.crc_hqx().

I have no opinion on that. I mean: in case of doubt, I prefer to not deprecate them. I never used any of these functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:52:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 09:52:11 +0000
Subject: =?utf-8?q?=5Bissue39355=5D_The_Python_library_will_not_compile_with_a_C++?=
 =?utf-8?q?2020_compiler_because_the_code_uses_the_reserved_=E2=80=9Cmodul?=
 =?utf-8?b?ZeKAnSBrZXl3b3Jk?=
In-Reply-To: <1579166721.74.0.203064876936.issue39355@roundup.psfhosted.org>
Message-ID: <1579168331.92.0.424018347317.issue39355@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Qt has a similar issue with "slots": bpo-1086854 and bpo-38007.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39355>
_______________________________________

From report at bugs.python.org  Thu Jan 16 04:52:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 09:52:47 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1579168367.63.0.436167720809.issue36051@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Thu Jan 16 05:02:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 10:02:58 +0000
Subject: [issue22486] Add math.gcd()
In-Reply-To: <1411591235.17.0.168367966743.issue22486@psf.upfronthosting.co.za>
Message-ID: <1579168978.27.0.334839991978.issue22486@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4691a2f2a2b8174a6c958ce6976ed5f3354c9504 by Victor Stinner in branch 'master':
bpo-39350: Remove deprecated fractions.gcd() (GH-18021)
https://github.com/python/cpython/commit/4691a2f2a2b8174a6c958ce6976ed5f3354c9504


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22486>
_______________________________________

From report at bugs.python.org  Thu Jan 16 05:02:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 10:02:58 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1579168978.19.0.954584416628.issue39350@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4691a2f2a2b8174a6c958ce6976ed5f3354c9504 by Victor Stinner in branch 'master':
bpo-39350: Remove deprecated fractions.gcd() (GH-18021)
https://github.com/python/cpython/commit/4691a2f2a2b8174a6c958ce6976ed5f3354c9504


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39350>
_______________________________________

From report at bugs.python.org  Thu Jan 16 05:03:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 10:03:19 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1579168999.54.0.342990905348.issue39350@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39350>
_______________________________________

From report at bugs.python.org  Thu Jan 16 05:05:06 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 16 Jan 2020 10:05:06 +0000
Subject: [issue39354] collections.UserString format and format_map return a
 string
In-Reply-To: <1579166333.43.0.0162767475956.issue39354@roundup.psfhosted.org>
Message-ID: <1579169106.62.0.335009821239.issue39354@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39354>
_______________________________________

From report at bugs.python.org  Thu Jan 16 05:16:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 10:16:20 +0000
Subject: [issue39353] Deprecate the binhex module
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579169780.33.0.404716481093.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I also found an answer suggesting to use binascii.a2b_hex() to decode a string the hexadecimal string "2020202020202020202020205635514d385a5856":
https://stackoverflow.com/questions/9683278/how-to-get-hard-disk-drivers-serial-number-in-python/9683837#9683837

Oh wait, it is just unrelated :-) It's a typo in the StackOverflow answer: "import binhex; binascii.a2b_hex(...)". It should be "import binascii" obviously ;-) I didn't notice at the first read. binhex has no a2b_hex() function :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Thu Jan 16 05:22:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 10:22:45 +0000
Subject: [issue39357] bz2: Remove deprecated buffering parameter of bz2.BZ2File
Message-ID: <1579170165.88.0.778090338845.issue39357@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The "buffering" parameter of bz2.BZ2File is deprecated for 12 years.

Using it was emitting a DeprecationWarning since Python 3.0.

Attached PR removes it.

----------
components: Library (Lib)
messages: 360114
nosy: vstinner
priority: normal
severity: normal
status: open
title: bz2: Remove deprecated buffering parameter of bz2.BZ2File
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39357>
_______________________________________

From report at bugs.python.org  Thu Jan 16 05:31:54 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 16 Jan 2020 10:31:54 +0000
Subject: =?utf-8?q?=5Bissue39355=5D_The_Python_library_will_not_compile_with_a_C++?=
 =?utf-8?q?2020_compiler_because_the_code_uses_the_reserved_=E2=80=9Cmodul?=
 =?utf-8?b?ZeKAnSBrZXl3b3Jk?=
In-Reply-To: <1579166721.74.0.203064876936.issue39355@roundup.psfhosted.org>
Message-ID: <1579170714.62.0.728129786974.issue39355@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Qt has different issue. "slots" is not a keyword, and the issue can be avoided by including Python.h before Qt.h or undefining the "slots" macro.

It could be a harder issue if "module" would be a field name of a public structure. But names of arguments are not part of the API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39355>
_______________________________________

From report at bugs.python.org  Thu Jan 16 05:36:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 10:36:10 +0000
Subject: [issue39357] bz2: Remove deprecated buffering parameter of bz2.BZ2File
In-Reply-To: <1579170165.88.0.778090338845.issue39357@roundup.psfhosted.org>
Message-ID: <1579170970.94.0.252648253677.issue39357@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17424
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18028

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39357>
_______________________________________

From report at bugs.python.org  Thu Jan 16 05:59:11 2020
From: report at bugs.python.org (Kresimir Kumericki)
Date: Thu, 16 Jan 2020 10:59:11 +0000
Subject: [issue35247] test.test_socket.RDSTest.testPeek hangs indefinitely
In-Reply-To: <1542212087.25.0.788709270274.issue35247@psf.upfronthosting.co.za>
Message-ID: <1579172351.49.0.180183164379.issue35247@roundup.psfhosted.org>


Kresimir Kumericki <kkumer at gmail.com> added the comment:

Sorry if this necrobumping is inappropriate, but I just experienced the same issue of test.test_socket.RDSTest.testPeek() hanging indefinitely, while trying to recompile Python 3.8.1 on Arch Linux.

----------
nosy: +kkumer
versions: +Python 3.8 -Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35247>
_______________________________________

From report at bugs.python.org  Thu Jan 16 06:57:57 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 16 Jan 2020 11:57:57 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1579175877.41.0.934780563792.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17425
pull_request: https://github.com/python/cpython/pull/18030

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Thu Jan 16 06:58:29 2020
From: report at bugs.python.org (Sergei Lebedev)
Date: Thu, 16 Jan 2020 11:58:29 +0000
Subject: [issue39358] test_code.CoExtra leads to double-free when ce_size >1
Message-ID: <1579175909.32.0.646555203336.issue39358@roundup.psfhosted.org>


New submission from Sergei Lebedev <slebedev at google.com>:

tl;dr Passing a Python function as a freefunc to _PyEval_RequestCodeExtraIndex leads to double-free. In general, I think that freefunc should not be allowed to call other Python functions.

---

test_code.CoExtra registers a new co_extra slot with a ctypes-wrapped freefunc

    # All defined in globals().
    LAST_FREED = None

    def myfree(ptr):
        global LAST_FREED
        LAST_FREED = ptr

    FREE_FUNC = freefunc(myfree)
    FREE_INDEX = RequestCodeExtraIndex(FREE_FUNC)

Imagine that we have registered another co_extra slot FOO_INDEX of type Foo and a freefunc FreeFoo. Furthermore, assume that 

* FOO_INDEX < FREE_INDEX
* FOO_INDEX is set on any executed code object including myfree. 

Consider what happens when we collect the globals() of the test_code module. myfree is referenced by globals() and FREE_FUNC. If FREE_FUNC is DECREF'd first, then by the time we get to myfree it has a refcount of 1 and DECREF'ing it leads to a code_dealloc call. Recall that the code object corresponding to myfree has two co_extra slots: 

* FOO_INDEX pointing to some Foo*, and
* FREE_INDEX with a value of NULL.

So, code_dealloc will first call FreeFoo (because FOO_INDEX < FREE_INDEX) and then the ctypes wrapper of myfree. The following sequence of calls looks roughly like this

_CallPythonObject
...
PyEval_EvalCodeEx
_PyEval_EvalCodeWithName
frame_dealloc
code_dealloc # !

The argument of the last code_dealloc call is *the same* myfree code object (!). This means that code_dealloc will attempt to call FreeFoo on an already free'd pointer leading to a crash.

----------
components: Tests
messages: 360117
nosy: slebedev
priority: normal
severity: normal
status: open
title: test_code.CoExtra leads to double-free when ce_size >1
type: crash
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39358>
_______________________________________

From report at bugs.python.org  Thu Jan 16 07:00:40 2020
From: report at bugs.python.org (Sergei Lebedev)
Date: Thu, 16 Jan 2020 12:00:40 +0000
Subject: [issue39358] test_code.CoExtra leads to double-free when ce_size >1
In-Reply-To: <1579175909.32.0.646555203336.issue39358@roundup.psfhosted.org>
Message-ID: <1579176040.16.0.72848635876.issue39358@roundup.psfhosted.org>


Change by Sergei Lebedev <slebedev at google.com>:


----------
nosy: +dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39358>
_______________________________________

From report at bugs.python.org  Thu Jan 16 07:08:52 2020
From: report at bugs.python.org (Maor Kleinberger)
Date: Thu, 16 Jan 2020 12:08:52 +0000
Subject: [issue34775] pathlib.PurePath division raises TypeError instead of
 returning NotImplemented
In-Reply-To: <1537686128.89.0.956365154283.issue34775@psf.upfronthosting.co.za>
Message-ID: <1579176532.98.0.998726753237.issue34775@roundup.psfhosted.org>


Change by Maor Kleinberger <kmaork at gmail.com>:


----------
pull_requests: +17426
pull_request: https://github.com/python/cpython/pull/12361

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34775>
_______________________________________

From report at bugs.python.org  Thu Jan 16 08:20:14 2020
From: report at bugs.python.org (Daniel Hillier)
Date: Thu, 16 Jan 2020 13:20:14 +0000
Subject: [issue39359] zipfile: add missing "pwd: expected bytes,
 got str" exception message
Message-ID: <1579180814.8.0.49279033626.issue39359@roundup.psfhosted.org>


New submission from Daniel Hillier <daniel.hillier at gmail.com>:

Setting the ZipFile.pwd attribute directly skips the check to ensure the password is a bytes object and, if not, return a user friendly TypeError("pwd: expected bytes, got <type>") informing them of that.

----------
components: Library (Lib)
messages: 360118
nosy: dhillier
priority: normal
severity: normal
status: open
title: zipfile: add missing "pwd: expected bytes, got str" exception message
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39359>
_______________________________________

From report at bugs.python.org  Thu Jan 16 08:23:44 2020
From: report at bugs.python.org (gaborbernat)
Date: Thu, 16 Jan 2020 13:23:44 +0000
Subject: [issue39360] python3.8 regression - ThreadPool join via __del__ hangs
 forever
Message-ID: <1579181024.48.0.144429938254.issue39360@roundup.psfhosted.org>


New submission from gaborbernat <gaborjbernat at gmail.com>:

Assume the following code:

```python
from multiprocessing.pool import ThreadPool
class A(object):
    def __init__(self):
        self.pool = ThreadPool()
    def __del__(self):
        self.pool.close()
        self.pool.join()
a = A()
print(a)
```

The code snippet above hangs forever on Python 3.8+ (works ok on Python 3.7 and earlier). An example output where I've added some extra prints on to the thread joins:

```
<__main__.A object at 0x1104d6070>
join thread <Thread(Thread-13, started daemon 123145699672064)> None
done
join thread <Thread(Thread-14, stopped daemon 123145716461568)> None
done
join thread <Thread(Thread-15, stopped daemon 123145733251072)> None
done
join thread <Thread(Thread-13, stopped daemon 123145699672064)> None
done
join thread <Thread(Thread-14, stopped daemon 123145716461568)> None
done
join thread <Thread(Thread-15, stopped daemon 123145733251072)> None
done
join thread <DummyProcess(Thread-1, stopped daemon 123145498198016)> None
done
join thread <DummyProcess(Thread-2, stopped daemon 123145514987520)> None
done
join thread <DummyProcess(Thread-3, stopped daemon 123145531777024)> None
done
join thread <DummyProcess(Thread-4, stopped daemon 123145548566528)> None
done
join thread <DummyProcess(Thread-5, started daemon 123145565356032)> None
```

I've tested on MacOs, but could replicate on Linux too within the CI.

----------
components: Library (Lib)
messages: 360119
nosy: gaborbernat, vstinner
priority: normal
severity: normal
status: open
title: python3.8 regression - ThreadPool join via __del__ hangs forever
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39360>
_______________________________________

From report at bugs.python.org  Thu Jan 16 08:24:17 2020
From: report at bugs.python.org (gaborbernat)
Date: Thu, 16 Jan 2020 13:24:17 +0000
Subject: [issue39360] python3.8 regression - ThreadPool join via __del__ hangs
 forever
In-Reply-To: <1579181024.48.0.144429938254.issue39360@roundup.psfhosted.org>
Message-ID: <1579181057.38.0.894435801082.issue39360@roundup.psfhosted.org>


Change by gaborbernat <gaborjbernat at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39360>
_______________________________________

From report at bugs.python.org  Thu Jan 16 08:42:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 13:42:41 +0000
Subject: [issue39360] python3.8 regression - ThreadPool join via __del__ hangs
 forever
In-Reply-To: <1579181024.48.0.144429938254.issue39360@roundup.psfhosted.org>
Message-ID: <1579182161.13.0.694512771968.issue39360@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39360>
_______________________________________

From report at bugs.python.org  Thu Jan 16 08:47:03 2020
From: report at bugs.python.org (Daniel Hillier)
Date: Thu, 16 Jan 2020 13:47:03 +0000
Subject: [issue39359] zipfile: add missing "pwd: expected bytes,
 got str" exception message
In-Reply-To: <1579180814.8.0.49279033626.issue39359@roundup.psfhosted.org>
Message-ID: <1579182423.44.0.44731381039.issue39359@roundup.psfhosted.org>


Change by Daniel Hillier <daniel.hillier at gmail.com>:


----------
keywords: +patch
pull_requests: +17427
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18031

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39359>
_______________________________________

From report at bugs.python.org  Thu Jan 16 08:47:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 13:47:29 +0000
Subject: [issue39361] [C API] Document PyTypeObject.tp_print removal in What's
 New In Python 3.9
Message-ID: <1579182449.25.0.646688097362.issue39361@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

commit aacc77fbd77640a8f03638216fa09372cc21673d
Author: Jeroen Demeyer <J.Demeyer at UGent.be>
Date:   Wed May 29 20:31:52 2019 +0200

    bpo-36974: implement PEP 590 (GH-13185)
    
    
    Co-authored-by: Jeroen Demeyer <J.Demeyer at UGent.be>
    Co-authored-by: Mark Shannon <mark at hotpy.org>

removed PyTypeObject.tp_print:

diff --git a/Include/cpython/object.h b/Include/cpython/object.h
index ba52a48358..a65aaf6482 100644
--- a/Include/cpython/object.h
+++ b/Include/cpython/object.h
@@ -182,7 +182,7 @@ typedef struct _typeobject {
     /* Methods to implement standard operations */
 
     destructor tp_dealloc;
-    printfunc tp_print;
+    Py_ssize_t tp_vectorcall_offset;
     getattrfunc tp_getattr;
     setattrfunc tp_setattr;
     PyAsyncMethods *tp_as_async; /* formerly known as tp_compare (Python 2)


Would it be possible to just document it in What's New in Python 3.9? Near:
https://docs.python.org/dev/whatsnew/3.9.html#build-and-c-api-changes


For example, this incompatible change broke zbar project:
https://bugzilla.redhat.com/show_bug.cgi?id=1791745

----------
components: C API
messages: 360120
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Document PyTypeObject.tp_print removal in What's New In Python 3.9
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39361>
_______________________________________

From report at bugs.python.org  Thu Jan 16 08:47:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 13:47:47 +0000
Subject: [issue36974] Implement PEP 590
In-Reply-To: <1559154718.16.0.347735090162.issue36974@roundup.psfhosted.org>
Message-ID: <1579182467.67.0.813754847632.issue36974@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-39361: [C API] Document PyTypeObject.tp_print removal in What's New In Python 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36974>
_______________________________________

From report at bugs.python.org  Thu Jan 16 09:09:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 14:09:24 +0000
Subject: [issue31031] Unify duplicate bits_in_digit and bit_length
In-Reply-To: <1500986884.91.0.522602979941.issue31031@psf.upfronthosting.co.za>
Message-ID: <1579183764.6.0.879275298442.issue31031@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset c5b79003f5fe6aa28a2a028680367839ba8677db by Victor Stinner (Niklas Fiekas) in branch 'master':
bpo-31031: Unify duplicate bits_in_digit and bit_length (GH-2866)
https://github.com/python/cpython/commit/c5b79003f5fe6aa28a2a028680367839ba8677db


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31031>
_______________________________________

From report at bugs.python.org  Thu Jan 16 09:13:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 14:13:46 +0000
Subject: [issue31031] Unify duplicate bits_in_digit and bit_length
In-Reply-To: <1500986884.91.0.522602979941.issue31031@psf.upfronthosting.co.za>
Message-ID: <1579184026.83.0.821921490508.issue31031@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

"On BSD, there's a library function called fls() that we could use, and GCC provides __builtin_clz()."

See also rejected bpo-29782 and GH-594.

If someone wants to experiment that, I suggest to add Include/internal/pycore_pymath.h, move _Py_bit_length() there and convert it to a static inline function.

Since the code is now unified, it makes a little bit more sense to add specialized code, *if* the code is not too complex.

I'm still not sure that GH-594 is worth it, since it was not possible to see the speedup on a microbenchmark :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31031>
_______________________________________

From report at bugs.python.org  Thu Jan 16 09:14:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 14:14:30 +0000
Subject: [issue31031] Unify duplicate bits_in_digit and bit_length
In-Reply-To: <1500986884.91.0.522602979941.issue31031@psf.upfronthosting.co.za>
Message-ID: <1579184070.16.0.693897734537.issue31031@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Niklas Fiekas for merging duplicated code ;-) It should make factorial_partial_product() a little bit more efficient!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31031>
_______________________________________

From report at bugs.python.org  Thu Jan 16 09:14:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 14:14:39 +0000
Subject: [issue31031] Unify duplicate bits_in_digit and bit_length
In-Reply-To: <1500986884.91.0.522602979941.issue31031@psf.upfronthosting.co.za>
Message-ID: <1579184079.82.0.409268411913.issue31031@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31031>
_______________________________________

From report at bugs.python.org  Thu Jan 16 09:33:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 14:33:34 +0000
Subject: [issue39357] bz2: Remove deprecated buffering parameter of bz2.BZ2File
In-Reply-To: <1579170165.88.0.778090338845.issue39357@roundup.psfhosted.org>
Message-ID: <1579185214.07.0.795965607344.issue39357@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9baf242fc733ab8a52a0b6201d95c6fdb8251745 by Victor Stinner in branch 'master':
bpo-39357: Remove buffering parameter of bz2.BZ2File (GH-18028)
https://github.com/python/cpython/commit/9baf242fc733ab8a52a0b6201d95c6fdb8251745


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39357>
_______________________________________

From report at bugs.python.org  Thu Jan 16 09:33:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 14:33:45 +0000
Subject: [issue39357] bz2: Remove deprecated buffering parameter of bz2.BZ2File
In-Reply-To: <1579170165.88.0.778090338845.issue39357@roundup.psfhosted.org>
Message-ID: <1579185225.51.0.738202786209.issue39357@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39357>
_______________________________________

From report at bugs.python.org  Thu Jan 16 09:56:43 2020
From: report at bugs.python.org (Forest)
Date: Thu, 16 Jan 2020 14:56:43 +0000
Subject: [issue39362] add option to make chunksize adaptive for
 multiprocessing.pool methods
Message-ID: <1579186602.99.0.0759376415978.issue39362@roundup.psfhosted.org>


New submission from Forest <fgregg at gmail.com>:

In the multiprocessing Pool methods like map, chunksize determines the trade-off between computation per task and inter-process communication. Setting chunksize appropriately has a large effect on efficiency.


However, for users directly interacting with the map methods, the way to find the appropriate chunksize is by manually checking different sizes and observing the program behavior.

For library developers, you have to hope that you set an reasonable value that will work okay across different hardware, operating systems, and task characteristics.

Generally, users of these methods want maximum throughput. It would be great if the map-like methods could adapt their chunksize towards that goal.

Something along the lines of this:

    n_items = 0
    queue = Queue(N)
    while True:
        chunk = tuple(itertools.islice(iterable, chunk_size))
        if chunk:
            queue.put(chunk)

            n_items += chunk_size
            i += 1

            if i % 10:
                time_delta = max(time.perf_counter() - t0, 0.0001)

                current_rate = n_items / time_delta

                # chunk_size is always either growing or shrinking, if
                # the shrinking led to a faster rate, keep
                # shrinking. Same with growing. If the rate decreased,
                # reverse directions
                if current_rate < last_rate:
                    multiplier = 1 / multiplier

                chunk_size = int(min(max(chunk_size * multiplier, 1), upper_bound))

                last_rate = current_rate
                n_items = 0
                t0 = time.perf_counter()


Would such a feature be desirable?

----------
components: macOS
messages: 360126
nosy: fgregg, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: add option to make chunksize adaptive for multiprocessing.pool methods

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39362>
_______________________________________

From report at bugs.python.org  Thu Jan 16 09:57:19 2020
From: report at bugs.python.org (Forest)
Date: Thu, 16 Jan 2020 14:57:19 +0000
Subject: [issue39362] add option to make chunksize adaptive for
 multiprocessing.pool methods
In-Reply-To: <1579186602.99.0.0759376415978.issue39362@roundup.psfhosted.org>
Message-ID: <1579186639.24.0.174221684355.issue39362@roundup.psfhosted.org>


Change by Forest <fgregg at gmail.com>:


----------
components: +Library (Lib) -macOS
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39362>
_______________________________________

From report at bugs.python.org  Thu Jan 16 10:57:08 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 16 Jan 2020 15:57:08 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579190228.02.0.184799498557.issue38076@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Executing this simple code after this commit segfaults:

from multiprocessing.pool import Pool
class A(object):
    def __init__(self):
        self.pool = Pool()
    def __del__(self):
        self.pool.close()
        self.pool.join()
a = A()

[1]    28019 segmentation fault  ./python.exe ../lel.py

The reason is that there is a call to PyModule_GetState with the module being NULL:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
  * frame #0: 0x00000001000b9737 python.exe`PyModule_GetState(m=0x0000000000000000) at moduleobject.c:565:10
    frame #1: 0x00000001013d5972 _struct.cpython-39d-darwin.so`s_pack(self=0x00000001032fae50, args=0x00000001033051f8, nargs=1) at _struct.c:1858:5
    frame #2: 0x00000001013d4a8a _struct.cpython-39d-darwin.so`pack(self=0x00000001013be890, args=0x00000001033051f0, nargs=2) at _struct.c:2165:14
    frame #3: 0x00000001000b6e5d python.exe`cfunction_vectorcall_FASTCALL(func=0x00000001013beb30, args=0x00000001033051f0, nargsf=9223372036854775810, kwnames=0x0000000000000000) at methodobject.c:380:24
    frame #4: 0x00000001001efa89 python.exe`_PyObject_Vectorcall(callable=0x00000001013beb30, args=0x00000001033051f0, nargsf=9223372036854775810, kwnames=0x0000000000000000) at abstract.h:106:21
    frame #5: 0x00000001001efbfa python.exe`call_function(tstate=0x0000000101003ec0, pp_stack=0x00007ffeefbf6e60, oparg=2, kwnames=0x0000000000000000) at ceval.c:4984:13
    frame #6: 0x00000001001ea00c python.exe`_PyEval_EvalFrameDefault(f=0x0000000103305050, throwflag=0) at ceval.c:3465:23
    frame #7: 0x00000001001d8c87 python.exe`PyEval_EvalFrameEx(f=0x0000000103305050, throwflag=0) at ceval.c:737:12
    frame #8: 0x000000010004374e python.exe`function_code_fastcall(co=0x0000000103165380, args=0x0000000103301400, nargs=2, globals=0x0000000103131d10) at call.c:293:14
    frame #9: 0x000000010004317a python.exe`_PyFunction_Vectorcall(func=0x000000010324d910, stack=0x00000001033013f0, nargsf=9223372036854775810, kwnames=0x0000000000000000) at call.c:331:20
    frame #10: 0x00000001001efa89 python.exe`_PyObject_Vectorcall(callable=0x000000010324d910, args=0x00000001033013f0, nargsf=9223372036854775810, kwnames=0x0000000000000000) at abstract.h:106:21
    frame #11: 0x00000001001efbfa python.exe`call_function(tstate=0x0000000101003ec0, pp_stack=0x00007ffeefbf8950, oparg=2, kwnames=0x0000000000000000) at ceval.c:4984:13
    frame #12: 0x00000001001ea09c python.exe`_PyEval_EvalFrameDefault(f=0x0000000103301250, throwflag=0) at ceval.c:3482:23
    frame #13: 0x00000001001d8c87 python.exe`PyEval_EvalFrameEx(f=0x0000000103301250, throwflag=0) at ceval.c:737:12
    frame #14: 0x00000001001f126c python.exe`_PyEval_EvalCodeWithName(_co=0x0000000103159930, globals=0x0000000103131d10, locals=0x0000000000000000, args=0x00000001032b2f68, argcount=2, kwnames=0x0000000000000000, kwargs=0x00000001032b2f78, kwcount=0, kwstep=1, defs=0x0000000103173f18, defcount=2, kwdefs=0x0000000000000000, closure=0x0000000000000000, name=0x000000010315c2e0, qualname=0x0000000103158430) at ceval.c:4296:14
    frame #15: 0x00000001000435d0 python.exe`_PyFunction_Vectorcall(func=0x000000010324d230, stack=0x00000001032b2f68, nargsf=9223372036854775810, kwnames=0x0000000000000000) at call.c:356:12
    frame #16: 0x00000001001efa89 python.exe`_PyObject_Vectorcall(callable=0x000000010324d230, args=0x00000001032b2f68, nargsf=9223372036854775810, kwnames=0x0000000000000000) at abstract.h:106:21
    frame #17: 0x00000001001efbfa python.exe`call_function(tstate=0x0000000101003ec0, pp_stack=0x00007ffeefbfa610, oparg=2, kwnames=0x0000000000000000) at ceval.c:4984:13
    frame #18: 0x00000001001ea09c python.exe`_PyEval_EvalFrameDefault(f=0x00000001032b2de0, throwflag=0) at ceval.c:3482:23
    frame #19: 0x00000001001d8c87 python.exe`PyEval_EvalFrameEx(f=0x00000001032b2de0, throwflag=0) at ceval.c:737:12
    frame #20: 0x000000010004374e python.exe`function_code_fastcall(co=0x00000001031d5860, args=0x0000000103302fd8, nargs=2, globals=0x00000001031d1b90) at call.c:293:14
    frame #21: 0x000000010004317a python.exe`_PyFunction_Vectorcall(func=0x0000000103256b90, stack=0x0000000103302fc8, nargsf=9223372036854775810, kwnames=0x0000000000000000) at call.c:331:20
    frame #22: 0x00000001001efa89 python.exe`_PyObject_Vectorcall(callable=0x0000000103256b90, args=0x0000000103302fc8, nargsf=9223372036854775810, kwnames=0x0000000000000000) at abstract.h:106:21
    frame #23: 0x00000001001efbfa python.exe`call_function(tstate=0x0000000101003ec0, pp_stack=0x00007ffeefbfc100, oparg=2, kwnames=0x0000000000000000) at ceval.c:4984:13
    frame #24: 0x00000001001ea09c python.exe`_PyEval_EvalFrameDefault(f=0x0000000103302e50, throwflag=0) at ceval.c:3482:23
    frame #25: 0x00000001001d8c87 python.exe`PyEval_EvalFrameEx(f=0x0000000103302e50, throwflag=0) at ceval.c:737:12
    frame #26: 0x000000010004374e python.exe`function_code_fastcall(co=0x000000010177aee0, args=0x0000000103306380, nargs=1, globals=0x00000001012a97d0) at call.c:293:14
    frame #27: 0x000000010004317a python.exe`_PyFunction_Vectorcall(func=0x0000000103252410, stack=0x0000000103306378, nargsf=9223372036854775809, kwnames=0x0000000000000000) at call.c:331:20
    frame #28: 0x00000001001efa89 python.exe`_PyObject_Vectorcall(callable=0x0000000103252410, args=0x0000000103306378, nargsf=9223372036854775809, kwnames=0x0000000000000000) at abstract.h:106:21
    frame #29: 0x00000001001efbfa python.exe`call_function(tstate=0x0000000101003ec0, pp_stack=0x00007ffeefbfdbf0, oparg=1, kwnames=0x0000000000000000) at ceval.c:4984:13
    frame #30: 0x00000001001ea09c python.exe`_PyEval_EvalFrameDefault(f=0x0000000103306200, throwflag=0) at ceval.c:3482:23
    frame #31: 0x00000001001d8c87 python.exe`PyEval_EvalFrameEx(f=0x0000000103306200, throwflag=0) at ceval.c:737:12
    frame #32: 0x000000010004374e python.exe`function_code_fastcall(co=0x0000000101251930, args=0x00007ffeefbfed20, nargs=1, globals=0x0000000101155b30) at call.c:293:14
    frame #33: 0x000000010004317a python.exe`_PyFunction_Vectorcall(func=0x00000001032535f0, stack=0x00007ffeefbfed18, nargsf=9223372036854775809, kwnames=0x0000000000000000) at call.c:331:20
    frame #34: 0x00000001000ec5b9 python.exe`_PyObject_Vectorcall(callable=0x00000001032535f0, args=0x00007ffeefbfed18, nargsf=9223372036854775809, kwnames=0x0000000000000000) at abstract.h:106:21
    frame #35: 0x00000001000ec422 python.exe`_PyObject_CallOneArg(func=0x00000001032535f0, arg=0x00000001012afc80) at abstract.h:144:12
    frame #36: 0x00000001000ec36a python.exe`call_unbound_noarg(unbound=1, func=0x00000001032535f0, self=0x00000001012afc80) at typeobject.c:1462:16
    frame #37: 0x00000001000e8220 python.exe`slot_tp_finalize(self=0x00000001012afc80) at typeobject.c:6815:15
    frame #38: 0x00000001002932ff python.exe`finalize_garbage(collectable=0x00007ffeefbfee38) at gcmodule.c:866:13
    frame #39: 0x000000010028fcd3 python.exe`collect(state=0x0000000100427890, generation=2, n_collected=0x0000000000000000, n_uncollectable=0x0000000000000000, nofail=1) at gcmodule.c:1098:5
    frame #40: 0x000000010028f9a9 python.exe`_PyGC_CollectNoFail at gcmodule.c:1851:13
    frame #41: 0x000000010022ff1c python.exe`_PyImport_Cleanup(tstate=0x0000000101003ec0) at import.c:560:5
    frame #42: 0x000000010025298e python.exe`Py_FinalizeEx at pylifecycle.c:1232:5
    frame #43: 0x000000010028d88d python.exe`Py_RunMain at main.c:648:9
    frame #44: 0x000000010028dc69 python.exe`pymain_main(args=0x00007ffeefbff080) at main.c:676:12
    frame #45: 0x000000010028dcb7 python.exe`Py_BytesMain(argc=2, argv=0x00007ffeefbff0f0) at main.c:700:12
    frame #46: 0x0000000100001482 python.exe`main(argc=2, argv=0x00007ffeefbff0f0) at python.c:16:12
    frame #47: 0x00007fff75bff3d5 libdyld.dylib`start + 1


I am marking this as a release blocked

----------
nosy: +pablogsal
priority: normal -> release blocker
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Thu Jan 16 11:27:33 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 16 Jan 2020 16:27:33 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1579192053.06.0.506149870413.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17428
pull_request: https://github.com/python/cpython/pull/18032

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Thu Jan 16 11:30:13 2020
From: report at bugs.python.org (gaborbernat)
Date: Thu, 16 Jan 2020 16:30:13 +0000
Subject: [issue39360] python3.8 regression - ThreadPool join via __del__ hangs
 forever
In-Reply-To: <1579181024.48.0.144429938254.issue39360@roundup.psfhosted.org>
Message-ID: <1579192213.45.0.699175097237.issue39360@roundup.psfhosted.org>


gaborbernat <gaborjbernat at gmail.com> added the comment:

An FYI update, the code is used by swagger-codegen to generate HTTP clients (https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/main/resources/python/api_client.mustache#L73). The example below basically replicates creating such client as a global.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39360>
_______________________________________

From report at bugs.python.org  Thu Jan 16 11:39:59 2020
From: report at bugs.python.org (Mariatta)
Date: Thu, 16 Jan 2020 16:39:59 +0000
Subject: [issue31862] Port the standard library to PEP 489 multiphase
 initialization
In-Reply-To: <1508857736.11.0.213398074469.issue31862@psf.upfronthosting.co.za>
Message-ID: <1579192799.93.0.428931494074.issue31862@roundup.psfhosted.org>


Change by Mariatta <mariatta at python.org>:


----------
pull_requests:  -13420

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31862>
_______________________________________

From report at bugs.python.org  Thu Jan 16 11:47:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 16:47:12 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579193232.09.0.907128999433.issue38076@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I can reproduce the crash on Linux. I interrupt the problem with CTRL+c (why is it blocked? I don't know). Then it does crash.

First, _PyImport_Cleanup() does clear all modules including _struct.

Then, _PyImport_Cleanup() calls gc.collect() which finalize_garbage() which calls A.__del__().

Problem: at this point, the _struct became unusable.

--

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x0000000000473f30 in PyModule_GetState (m=0x0) at Objects/moduleobject.c:565
565	    if (!PyModule_Check(m)) {
(gdb) py-bt
Traceback (most recent call first):
  <built-in method pack of module object at remote 0x7fffea99acb0>
  File "/home/vstinner/python/master/Lib/multiprocessing/connection.py", line 400, in _send_bytes
    header = struct.pack("!i", n)
  File "/home/vstinner/python/master/Lib/multiprocessing/connection.py", line 200, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "/home/vstinner/python/master/Lib/multiprocessing/queues.py", line 368, in put
    self._writer.send_bytes(obj)
  File "/home/vstinner/python/master/Lib/multiprocessing/pool.py", line 649, in close
    self._change_notifier.put(None)
  File "/home/vstinner/python/master/x.py", line 7, in __del__
    self.pool.close()
  Garbage-collecting

In debug mode, the crash occurs in s_pack() at:

    assert(PyStruct_Check(self));

--

#define _structmodulestate(o) ((_structmodulestate *)PyModule_GetState(o))

static struct PyModuleDef _structmodule;

#define _structmodulestate_global _structmodulestate(PyState_FindModule(&_structmodule))

#define PyStruct_Check(op) PyObject_TypeCheck(op, (PyTypeObject *)_structmodulestate_global->PyStructType)

The problem is "_structmodulestate_global->PyStructType": PyState_FindModule(&_structmodule) returns NULL, _structmodulestate() calls PyModule_GetState(NULL) which does crash.

--

The question is why the _struct module was cleared whereas there was still a reference to it. Is it part of a reference cycle?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Thu Jan 16 11:48:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 16:48:05 +0000
Subject: [issue39360] python3.8 regression - ThreadPool join via __del__ hangs
 forever
In-Reply-To: <1579181024.48.0.144429938254.issue39360@roundup.psfhosted.org>
Message-ID: <1579193285.32.0.293497997044.issue39360@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This code snippet seems to trigger a crash in the _struct module:
https://bugs.python.org/issue38076#msg360127

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39360>
_______________________________________

From report at bugs.python.org  Thu Jan 16 11:54:03 2020
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 16 Jan 2020 16:54:03 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579193643.93.0.735915735554.issue38076@roundup.psfhosted.org>


Change by Dino Viehland <dinoviehland at gmail.com>:


----------
nosy: +eelizondo -dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Thu Jan 16 12:08:15 2020
From: report at bugs.python.org (gaborbernat)
Date: Thu, 16 Jan 2020 17:08:15 +0000
Subject: [issue39360] python3.8 regression - ThreadPool join via __del__ hangs
 forever
In-Reply-To: <1579181024.48.0.144429938254.issue39360@roundup.psfhosted.org>
Message-ID: <1579194495.56.0.565541661102.issue39360@roundup.psfhosted.org>


gaborbernat <gaborjbernat at gmail.com> added the comment:

Reported the issue downstream too under https://github.com/swagger-api/swagger-codegen/issues/9991

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39360>
_______________________________________

From report at bugs.python.org  Thu Jan 16 12:25:23 2020
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 16 Jan 2020 17:25:23 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579195523.79.0.861791158223.issue38076@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

It seems problematic that_PyInterpreterState_ClearModules runs before all instances from a module have been cleared.  If PyState_FindModule is no longer able to return module state then there's no way for a module to reliably work at shutdown other than having all instances hold onto the module (or module state) directly from all of their insatances.  Certainly that would mimic more closely what happens w/ pure Python instances and modules - the type will hold onto the functions which will hold onto the module global state.

----------
nosy: +dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Thu Jan 16 12:35:03 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 16 Jan 2020 17:35:03 +0000
Subject: [issue39360] python3.8 regression - ThreadPool join via __del__ hangs
 forever
In-Reply-To: <1579181024.48.0.144429938254.issue39360@roundup.psfhosted.org>
Message-ID: <1579196103.36.0.1543474467.issue39360@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This is not a regression: the code only worked on 3.7 because there is a sleep in the pool maintainance loop that makes the pool more likely being more consistent, but is the same problem as there is a race condition. For example, reducing the sleep in the loop (notice 3.8 does not use a sleep but instead uses a more resilient system of sentinels) for the 3.7 version reproduces the problem:

diff --git a/Lib/multiprocessing/pool.py b/Lib/multiprocessing/pool.py
index 3e9a0d6b48..f8d438d87c 100644
--- a/Lib/multiprocessing/pool.py
+++ b/Lib/multiprocessing/pool.py
@@ -410,7 +410,7 @@ class Pool(object):
         # is terminated.
         while thread._state == RUN or (pool._cache and thread._state != TERMINATE):
             pool._maintain_pool()
-            time.sleep(0.1)
+            time.sleep(0.00000001)
         # send sentinel to stop workers
         pool._taskqueue.put(None)
         util.debug('worker handler exiting')

With that patch, 3.7 hangs as well. The problem here is that something regarding the locks inside the SimpleQueue of inbound tasks is not in a consistent state when Python finalization calls __del__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39360>
_______________________________________

From report at bugs.python.org  Thu Jan 16 12:49:19 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 16 Jan 2020 17:49:19 +0000
Subject: [issue39362] add option to make chunksize adaptive for
 multiprocessing.pool methods
In-Reply-To: <1579186602.99.0.0759376415978.issue39362@roundup.psfhosted.org>
Message-ID: <1579196959.13.0.996550048436.issue39362@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +davin, pitrou -ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39362>
_______________________________________

From report at bugs.python.org  Thu Jan 16 13:07:25 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 16 Jan 2020 18:07:25 +0000
Subject: [issue39362] add option to make chunksize adaptive for
 multiprocessing.pool methods
In-Reply-To: <1579186602.99.0.0759376415978.issue39362@roundup.psfhosted.org>
Message-ID: <1579198045.06.0.434891047443.issue39362@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39362>
_______________________________________

From report at bugs.python.org  Thu Jan 16 13:24:07 2020
From: report at bugs.python.org (maxime-lemonnier)
Date: Thu, 16 Jan 2020 18:24:07 +0000
Subject: [issue39363] zipfile with multiprocessing: zipfile.BadZipFile
Message-ID: <1579199047.32.0.379077143522.issue39363@roundup.psfhosted.org>


New submission from maxime-lemonnier <maxime.lemonnier at gmail.com>:

zipfile sometimes throws zipfile.BadZipFile when opening the same zip file from multiple processes

see attached file to reproduce the error. You'll need a zipfile with multiple files in it to reproduce.

----------
components: Library (Lib)
files: test_filesource.py
messages: 360134
nosy: maxime-lemonnier
priority: normal
severity: normal
status: open
title: zipfile with multiprocessing: zipfile.BadZipFile
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file48847/test_filesource.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39363>
_______________________________________

From report at bugs.python.org  Thu Jan 16 13:24:25 2020
From: report at bugs.python.org (maxime-lemonnier)
Date: Thu, 16 Jan 2020 18:24:25 +0000
Subject: [issue39363] zipfile with multiprocessing: zipfile.BadZipFile
In-Reply-To: <1579199047.32.0.379077143522.issue39363@roundup.psfhosted.org>
Message-ID: <1579199065.3.0.668123503839.issue39363@roundup.psfhosted.org>


Change by maxime-lemonnier <maxime.lemonnier at gmail.com>:


Added file: https://bugs.python.org/file48848/foo_bar_small.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39363>
_______________________________________

From report at bugs.python.org  Thu Jan 16 13:32:16 2020
From: report at bugs.python.org (maxime-lemonnier)
Date: Thu, 16 Jan 2020 18:32:16 +0000
Subject: [issue39363] zipfile with multiprocessing: zipfile.BadZipFile
In-Reply-To: <1579199047.32.0.379077143522.issue39363@roundup.psfhosted.org>
Message-ID: <1579199536.37.0.412067455081.issue39363@roundup.psfhosted.org>


maxime-lemonnier <maxime.lemonnier at gmail.com> added the comment:

Here's my console output:

python3 test_filesource.py
lock
file
access_mode = file, nb processes = 1, res = 110289, 0.08039402961730957 ms/frame
file
access_mode = file, nb processes = 4, res = 110289, 0.32297492027282715 ms/frame
lock
access_mode = lock, nb processes = 4, res = 110289, 0.2950408458709717 ms/frame
lock
multiprocessing.pool.RemoteTraceback: 
"""
Traceback (most recent call last):
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 119, in worker
    result = (True, func(*args, **kwds))
  File "/path/to/script/test_filesource.py", line 64, in read_small
    return fs_small[i%len(fs_small)][42]
  File "/path/to/script/test_filesource.py", line 55, in __getitem__
    data_bytes = self.access( lambda archive: archive.read(member))
  File "/path/to/script/test_filesource.py", line 27, in access_lock
    return f(self.archive)
  File "/path/to/script/test_filesource.py", line 55, in <lambda>
    data_bytes = self.access( lambda archive: archive.read(member))
  File "/usr/lib/python3.6/zipfile.py", line 1337, in read
    with self.open(name, "r", pwd) as fp:
  File "/usr/lib/python3.6/zipfile.py", line 1419, in open
    % (zinfo.orig_filename, fname))
zipfile.BadZipFile: File name in directory '00000005.pkl' and header b'00000004.pkl' differ.
"""

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/path/to/script/test_filesource.py", line 90, in <module>
    f(4, "lock") #crash
  File "/path/to/script/test_filesource.py", line 81, in f
    for i in pool.imap_unordered(read_small, frames):
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 735, in next
    raise value
zipfile.BadZipFile: File name in directory '00000005.pkl' and header b'00000004.pkl' differ.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39363>
_______________________________________

From report at bugs.python.org  Thu Jan 16 14:38:56 2020
From: report at bugs.python.org (Mariatta)
Date: Thu, 16 Jan 2020 19:38:56 +0000
Subject: [issue38342] ImportError: cannot import name 'MetadataPathFinder'
 from 'importlib.metadata'
In-Reply-To: <1569968531.94.0.379845933414.issue38342@roundup.psfhosted.org>
Message-ID: <1579203536.43.0.821539555247.issue38342@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

Just wanted to add that I got the same error in Python 3.8.1. 

I ran the script that @Jaraco wrote above:

python -c "import importlib.metadata, shutil, pathlib; file = pathlib.Path(importlib.metadata.__file__); str(file).endswith('__init__.py') and shutil.rmtree(file.parent) and print('removed', file.parent)"

I wonder if the fix (e.g. running the script above) should be more visible, perhaps in some documentation somewhere, instead of having to dig this up from the bugtracker.

Is it possible for the Python installer itself to execute that script?

Thanks.

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38342>
_______________________________________

From report at bugs.python.org  Thu Jan 16 14:40:37 2020
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 16 Jan 2020 19:40:37 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579203637.08.0.433413726635.issue38076@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

This is a relatively simple repro of the underlying problem:

import _struct

s = _struct.Struct('i')

class C:
    def __del__(self):
        s.pack(42, 100)

_struct.x = C()

It's a little bit different in that it is actually causing the module to attempt to throw an exception instead of do a type check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Thu Jan 16 14:47:40 2020
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 16 Jan 2020 19:47:40 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579204060.37.0.580519928886.issue38076@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

And here's a variation which doesn't involve any instances from the module:

import _struct

class C:
    def __init__(self):
        self.pack = _struct.pack
    def __del__(self):
        self.pack('I', -42)

_struct.x = C()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Thu Jan 16 14:55:34 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 16 Jan 2020 19:55:34 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579204534.9.0.697865468774.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> Later, I closed my pysandbox beause it was "broken by design":
https://lwn.net/Articles/574215/

Thanks for the link, insightful. Still unclear, by design of what it's broken ;-).


> Paul Sokolovsky wrote in bpo-36220 than his idea is also to implement a sandbox

Depends on the definition of "sandbox". If it's "But I was contacted by
different companies interested to use pysandbox in production on their
web application.  So I think that there is a real need to execute
arbitrary untrusted code." (re: https://lwn.net/Articles/574323/). Then no, I definitely not developing such a "sandbox".

If by "sandbox" you mean "ability to override some namespacing rules used by Python", then yep, I, and other folks (according to these >1 issue reports) interested in that. It's unclear why demise of your particular project should affect all other possible projects interested in dealing with namespacing matters. I for example interested in study of some properties of corpus of Python code. I can understand your claim that you "own" the partial features you introduced, but claiming them to be useful for only our own usecase is somewhat ..., well, short-sighted, just as claiming that all such uses should cease and desist is as insightful as claiming that, for example, list comprehensions are useless because you faced a case when one needs to be rewritten as explicit loop.

> IMHO we should reject dict subclasses to make Python (especially ceval.c) more efficient.

I'm afraid efficiency story for CPython is irrecoverably lost, unless someone secretly works on adding JIT to it, but as we know, JIT work happily happens outside of it, in multiples. CPython still can either serve as a common platform for prototyping and experimentation, or complicate that by a committee fiat. Because the current situation is that CPython is too dynamic to be "slow", but not enough dynamic to perform useful instrumentation easily. For example, to comfortably do study on the proportions of actual usage of various "overdynamic" features.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 14:57:28 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 16 Jan 2020 19:57:28 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579204648.71.0.83145611972.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

s/only our own usecase/only your own usecase/ (missing "y" typo)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 15:09:30 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 16 Jan 2020 20:09:30 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579205370.17.0.943524230316.issue32615@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 15:25:30 2020
From: report at bugs.python.org (ppperry)
Date: Thu, 16 Jan 2020 20:25:30 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579206330.11.0.510371169386.issue32615@roundup.psfhosted.org>


ppperry <mapreader at olum.org> added the comment:

I was not attempting to run untrusted Python code when I filed this bug report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 15:45:40 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 16 Jan 2020 20:45:40 +0000
Subject: [issue36220] LOAD_NAME and LOAD_GLOBAL,
 STORE_GLOBAL handle dict subclasses for globals() differently
In-Reply-To: <1551930086.95.0.70586200648.issue36220@roundup.psfhosted.org>
Message-ID: <1579207540.83.0.473931135808.issue36220@roundup.psfhosted.org>


Change by Paul Sokolovsky <pfalcon at users.sourceforge.net>:


----------
pull_requests: +17429
pull_request: https://github.com/python/cpython/pull/18033

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36220>
_______________________________________

From report at bugs.python.org  Thu Jan 16 15:47:31 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 16 Jan 2020 20:47:31 +0000
Subject: [issue31485] Tkinter widget.unbind(sequence,
 funcid) unbind all bindings
In-Reply-To: <1505483834.38.0.808110743528.issue31485@psf.upfronthosting.co.za>
Message-ID: <1579207651.17.0.895372571544.issue31485@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Serhiy, if I understand your last message (msg302299), the docstring should read:

       Unbind for this widget the event SEQUENCE.
       If FUNCID is given, only unbind the function identified with FUNCID
       and also delete that command.

The main doc change is to specify what happens when funcid is not given while the code change in the patch is to no longer unbind everything when funcid *is* given.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31485>
_______________________________________

From report at bugs.python.org  Thu Jan 16 15:51:16 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 16 Jan 2020 20:51:16 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579207876.5.0.153585613261.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

Ok, so the patch for my usecase (STORE_GLOBAL) is vividly trivial, so to go thru the full circle, I posted it: https://github.com/python/cpython/pull/18033 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 15:53:43 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 16 Jan 2020 20:53:43 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579208023.45.0.934659718042.issue32615@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> IMHO we should reject dict subclasses to make Python (especially ceval.c) more efficient. The global type must be checked at every place where it's possible to specify or override globals. Like the exec() function.

I agree with Victor in that we should reject dict subclasses everywhere.

----------
keywords: +3.6regression

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 16:37:07 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 16 Jan 2020 21:37:07 +0000
Subject: [issue31485] Tkinter widget.unbind(sequence,
 funcid) unbind all bindings
In-Reply-To: <1505483834.38.0.808110743528.issue31485@psf.upfronthosting.co.za>
Message-ID: <1579210627.4.0.134091898719.issue31485@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Serhiy, given that the code did not match the docstring and that we are changing the code to match the clarified docstring, should we consider this a bugfix, and, should we backport it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31485>
_______________________________________

From report at bugs.python.org  Thu Jan 16 16:38:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 21:38:19 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579210699.4.0.249012728044.issue32615@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Depends on the definition of "sandbox".

In bpo-36220, it clearly means "execute untrusted code": hide access to the filesystem for example.


> I for example interested in study of some properties of corpus of Python code.

This issue is a feature request: you ask to modify Python so you can pass dict subclasses as namespaces and expect CPython to respect the mapping protocol (__getitem__/__setitem__, rather than accessing directly dict internals (well, don't call overriden __getitem__/__setitem__ methods).

Currently, we are in a gray area: it's supported in some places, but not everywhere.

Implementing such features which require to introduce new code, which means increasing the maintenance burden, and it will slow down Python, since every access to a namespace would require to check if the namespace is a dict or a dict subclass.

Paul: you're are in front of 3 core developers who are rejecting your feature request. It doesn't mean that it is not valid. It means that we don't consider your use case as important enough to justify to slow down Python for everything and to increase the maintenance burden.

Namespace performances are really critical for overall Python performances.

My idea is only to reject the feature in CPython implementation, not the in Python language specification. It means that other Python implementation would be free to decide to implement it.

You're free to fork Python and modify the C code to implement your use case, to study Python internals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 16:44:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 21:44:26 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579211066.63.0.584349219326.issue32615@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

More detail about the implementation. Currently, namespaces are accessed directly with C functions which expect to get an exact dict type: these functions are designed for performance, not to handle dict subclasses, on purpose.

Supporting dict subclasses first require to check if the namespace type is dict: that's the first performance overhead. Then new code should be added to handle subclasses: that's the additional maintenance burden. This code path should be tested, maintained, reviewed, etc.

The risk is also to forget to support subclasses in one function which would break the feature. Same problem is new code is added which doesn't support dict subclasses.

This feature is far from being free to implement. It's very expensive on multiple aspects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 17:05:46 2020
From: report at bugs.python.org (alex c)
Date: Thu, 16 Jan 2020 22:05:46 +0000
Subject: [issue39364] Automatically tabulate module contents in the docs
Message-ID: <1579212346.83.0.45042082539.issue39364@roundup.psfhosted.org>


New submission from alex c <alexchandel at gmail.com>:

By default, the docs.python.org page for a module does not list or tabulate the contents of that module. This makes it difficult to browse a module's functions or get a bird's-eye view.

For example, the logging module (https://docs.python.org/3/library/logging.html) has almost 70 functions, methods, and attributes. But it's impossible to scan them without scrolling the entire length of the entry (~18 pages of US letter). Compare to the browsability of itertools (https://docs.python.org/3/library/itertools.html), which manually tabulates its functions in the first section.

docs.python.org should automatically generate a TOC of the module's contents (classes, functions, etc) in the navigation sidebar, below the existing sidebar sections (perhaps in a collapsible section). Rust's documentation does this (example: https://doc.rust-lang.org/std/time/struct.Duration.html), and doc.rust-lang.org also effectively allows the entire page to function as a TOC by providing a "collapse page" button.

----------
assignee: docs at python
components: Documentation
messages: 360148
nosy: alexchandel, docs at python
priority: normal
severity: normal
status: open
title: Automatically tabulate module contents in the docs
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39364>
_______________________________________

From report at bugs.python.org  Thu Jan 16 17:18:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 16 Jan 2020 22:18:38 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579213118.04.0.33684352053.issue32615@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

exec() function is currently quite clear on which types are accepted or not: exact dict for globals, mapping for locals.

*  "If only globals is provided, it must be a dictionary (and not a subclass of dictionary), which will be used for both the global and the local variables."
* "If provided, locals can be any mapping object."

Moreover, the requirement on the exact dict type allowed to implement an optimization on globals in Python 3.8:

"LOAD_GLOBAL instruction now uses new ?per opcode cache? mechanism. It is about 40% faster now. (Contributed by Yury Selivanov and Inada Naoki in bpo-26219.)"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 17:55:02 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 16 Jan 2020 22:55:02 +0000
Subject: [issue38342] ImportError: cannot import name 'MetadataPathFinder'
 from 'importlib.metadata'
In-Reply-To: <1569968531.94.0.379845933414.issue38342@roundup.psfhosted.org>
Message-ID: <1579215302.9.0.767449909228.issue38342@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Given that this issue only affects those who upgraded from beta versions, I'm inclined to say it shouldn't be part of the installer, and that the long tail of users affected probably can track it down here.

I don't feel strongly about it though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38342>
_______________________________________

From report at bugs.python.org  Thu Jan 16 18:06:29 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 16 Jan 2020 23:06:29 +0000
Subject: [issue39308] Literal[True] prints as Literal[1] in some cases
In-Reply-To: <1578785715.62.0.203170094807.issue39308@roundup.psfhosted.org>
Message-ID: <1579215989.6.0.0341299238783.issue39308@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

In the PR (https://github.com/python/cpython/pull/17974) we found that there's no great solution for this. This issue will probably linger for a while, but maybe we should just set an example and close it, since we're unlikely to take any action?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39308>
_______________________________________

From report at bugs.python.org  Thu Jan 16 18:16:29 2020
From: report at bugs.python.org (Jack O'Connor)
Date: Thu, 16 Jan 2020 23:16:29 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1579216589.72.0.987712589395.issue39298@roundup.psfhosted.org>


Jack O'Connor <oconnor663 at gmail.com> added the comment:

Ok, I've added Rust bindings to the BLAKE3 C implementation, so that I can benchmark it in a vaguely consistent way. My laptop is an i5-8250U, which should be very similar to yours. (Both are "Kaby Lake Refresh".) My end result do look similar to yours with TurboBoost on, but pretty different with TurboBoost off:

with TurboBoost on
------------------
K12 GCC        | 2159 MB/s
BLAKE3 Rust    | 1787 MB/s
BLAKE3 C Clang | 1588 MB/s
BLAKE3 C GCC   | 1453 MB/s

with TurboBoost off
-------------------
BLAKE3 Rust    | 1288 MB/s
K12 GCC        | 1060 MB/s
BLAKE3 C Clang | 1094 MB/s
BLAKE3 C GCC   |  943 MB/s

The difference seems to be that with TurboBoost on, the BLAKE3 benchmarks have my CPU sitting around 2.4 GHz, while for the K12 benchmarks it's more like 2.9 GHz. With TurboBoost off, both benchmarks run at 1.6 GHz, and BLAKE3 does better. I'm not sure what causes that frequency difference. Perhaps some high-power instruction that the BLAKE3 implementation is emitting?

To reproduce these numbers you can clone these two repos (the latter is where I happen to have a K12 benchmark):

https://github.com/BLAKE3-team/BLAKE3
https://github.com/oconnor663/blake2_simd

Then in both cases checkout the "bench_406668786" branch, where I've put some benchmarks with the same input length you used.

For Rust BLAKE3, at the root of the BLAKE3 repo, run: cargo +nightly bench 406668786

For C BLAKE3, the command is the same, but run it in the "./c/blake3_c_rust_bindings" directory. The build defaults to GCC, and you can "export CC=clang" to switch it.

For my K12 benchmark, at the root of the blake2_simd repo, run: cargo +nightly bench --features=kangarootwelve 406668786

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Thu Jan 16 18:32:05 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 16 Jan 2020 23:32:05 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579217525.56.0.295427998155.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> you ask to modify Python so you can pass dict subclasses as namespaces and expect CPython to respect the mapping protocol

But no, per your own account, you made noticeable, though not complete, code changes in that direction. The only thing I'm saying "now that it's all there, it's only logical to fix the missing parts, about which people report issues". While you suddenly come up with "alternative" solution - throw it all away.

And I always just took your word for it, but now did some git logging/blaming. So, LOAD_GLOBAL handling of dict subclasses was introduced by you in https://github.com/python/cpython/commit/b0b224233e481d979430a54d257d871424ff19fb , in 2012, almost 8 years ago. 

And what about STORE_NAME handling? I traced that to https://github.com/python/cpython/commit/214b1c3aaea3e83302df9ea37a37b3c7548b92b1 of 2004.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 18:33:02 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 16 Jan 2020 23:33:02 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579217582.45.0.275762169624.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> Paul: you're are in front of 3 core developers who are rejecting your feature request.

But no, it's not my feature request. There were 2 tickets by at least 2 people. I just saw my case to be similar to cases of those people, so instead of creating duplicate bug reports, I chimed in, to show the general issue: various name-related opcodes don't treat namespace objects consistently.

And if I'm in front on 3 core developers here, then only because someone's Rubber Ducky (https://en.wikipedia.org/wiki/Rubber_duck_debugging) took a good vacation. Because I may imagine following "debugging session":

- Hey Ducky, some time ago I hacked on one project. As you know, I'm a core developer, so I kinda can add things on my whim, so I added some stuff to CPython core for that project, not consistent, not complete. Since then, I lost interest in my project, and as you can imagine, couldn't care less about the code in the core. The problem? It was almost 8 years ago. People discovered those features, and came to use on them. Not only that, they raise heads and demand it to be implemented more thoroughly and consistently. So, don't you think now would be good time to punish them and just rip that code out?

- You say how could I possible to do that on my own? No worries, I have 2 more buddies vouching for me, we core developers never let each other down.

- You're saying that removing features after 8 years is problematic? No worries, we can always say it was a regression from just 3 years ago.

- Hey Ducky, there's a more problem still, there's a particularly obnoxious dude, who initially tried to argue need for adding a feature based on my 8-year old code. If we support stuff in LOAD_GLOBAL, he says, then it should be piece of cake to support it in STORE_GLOBAL, which is called much less frequently. But we got him into the cold with a news of removal that 8-year code. Still he can't calm down, and changing tactics arguing that due to the way that globals are used at the module level (as locals too), then STORE_GLOBAL should behave consistently with STORE_NAME, tossing some pretty simple exec() code showing inconsistency. Should we just ignore him, or go for total punishment and make it "consistent" just the same as above, by removing support in STORE_NAME, instead of adding to STORE_GLOBAL? Now, that code is 16 years old. Do you think we can go for a twist like that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 18:34:27 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 16 Jan 2020 23:34:27 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579217667.39.0.482927962063.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> Namespace performances are really critical for overall Python performances.

Yeah, that's why I'd like for myself and other people to make it easy to explore the behavior of namespace lookups, to see how to optimize them.


> You're free to fork Python and modify the C code to implement your use case, to study Python internals.

Thanks, already done. I'm now looking for a way to share those studies with other people, who won't patch and compile CPython. So, no worries, I've already lost, I need that fix yesterday, in actual versions of CPython deployed around the world. The rest if just idea that bugs which aren't fixed, persist; and the very interesting case of decision making by CPython core developers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 18:43:32 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 16 Jan 2020 23:43:32 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579218212.09.0.407875785897.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> exec() function is currently quite clear

A recent case: https://bugs.python.org/issue38316, co_stacksize was quite clear what it is. Turned out, a bug in the documentation (likely, just someone forgot to update it to the actual code). That's just one case, there're tons of bugs in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Thu Jan 16 19:07:47 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 17 Jan 2020 00:07:47 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579219667.46.0.989070006065.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have been playing with the API for a while and I have to say that I have fallen in love with it: I tried to reimplement many snippets of parallel and non-parallel topological-order processing of a graph with this and it always fits very nicely.

I have shown this API also to some library maintainers that have to deal with topological sorting (like the tox maintainer) and they are very enthusiastic about the API as well.

Tim, I have updated PR 11583 to use the proposed API with test and docs. Could you make a review when you have some time so we can polish it for the 3.9 release?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Thu Jan 16 23:23:15 2020
From: report at bugs.python.org (random832)
Date: Fri, 17 Jan 2020 04:23:15 +0000
Subject: [issue39365] Support (SEEK_END/SEEK_CUR) relative seeking in StringIO
Message-ID: <1579234995.29.0.127298904142.issue39365@roundup.psfhosted.org>


New submission from random832 <random832 at fastmail.us>:

Currently this fails with a (misleading in the case of SEEK_END) "Can't do nonzero cur-relative seeks" error, but there's no conceptual reason it shouldn't be possible.

The offset should simply be taken as a character offset, without any pretense that the "file" represents bytes in some Unicode encoding. This is already done for SEEK_START and tell, and has not caused any problems.

----------
components: IO
messages: 360158
nosy: random832
priority: normal
severity: normal
status: open
title: Support (SEEK_END/SEEK_CUR) relative seeking in StringIO
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39365>
_______________________________________

From report at bugs.python.org  Thu Jan 16 23:32:40 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 17 Jan 2020 04:32:40 +0000
Subject: [issue39354] collections.UserString format and format_map return a
 string
In-Reply-To: <1579166333.43.0.0162767475956.issue39354@roundup.psfhosted.org>
Message-ID: <1579235560.04.0.0309965226495.issue39354@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

It is too late is the life of UserString for a design change, so I'm going to have to close this as more likely to harm existing code than to benefit future code.

Also, despite you expectations, this isn't atypical for Python classes.  For example, the __add__ method on integer subclasses returns actual ints rather than instances of the subclass.

In the case of UserString, the current design can be useful because it make UserString instances more substitutable for regular strings.

----------
nosy: +rhettinger
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39354>
_______________________________________

From report at bugs.python.org  Fri Jan 17 00:01:38 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 17 Jan 2020 05:01:38 +0000
Subject: [issue39349] Add "cancel_futures" parameter to
 concurrent.futures.Executor.shutdown()
In-Reply-To: <1579147714.25.0.252393666546.issue39349@roundup.psfhosted.org>
Message-ID: <1579237298.63.0.667031175149.issue39349@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

As of now, I have the implementation for ThreadPoolExecutor working correctly, and a unit test added to ensure its behavior. It was a bit more involved than I originally anticipated, as I had to make a minor change in the _worker() function to allow the new parameter to be compatible with wait (which is important, as it prevents dangling threads).

With my initial implementation, using "wait=True" and "cancel_futures=True" was resulting in any threads that called work_queue.get(block=True) to hang indefinitely. In order to remedy this, I changed it to use work_queue.get_nowait(). If a queue.Empty exception occurs, it checks for a global constant _cancelling_futures (set to True just in shutdown before it starts draining the work queue). If it's true, the while True loop is broken, otherwise it continues to the next iteration. This effectively has the same behavior as before. 

I experimented with a few different possible solutions, and the above was the only one that worked while still maintaining the current behavior as much as possible. From what I can tell, this was the only viable means of implementing the new parameter without making it entirely incompatible with "wait=True".

At this point, I believe the only remaining step for the ThreadPoolExecutor implementation is to update the documentation and decide on the name. After working with it, I'm leaning more towards *cancel_futures*, as I think this more accurately describes what it does compared to just *cancel* (which is a bit vague IMO).

----------
title: Add "cancel" parameter to concurrent.futures.Executor.shutdown() -> Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39349>
_______________________________________

From report at bugs.python.org  Fri Jan 17 00:51:12 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 17 Jan 2020 05:51:12 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579240272.33.0.962291493448.issue32615@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
superseder:  -> Allow mappings as globals (was: Fix dictionary subclass ...)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Fri Jan 17 01:43:55 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 17 Jan 2020 06:43:55 +0000
Subject: [issue38840] incorrect __all__ list in multiprocessing.managers module
In-Reply-To: <1574115502.48.0.329816372934.issue38840@roundup.psfhosted.org>
Message-ID: <1579243435.88.0.978379530569.issue38840@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +17430
pull_request: https://github.com/python/cpython/pull/18034

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38840>
_______________________________________

From report at bugs.python.org  Fri Jan 17 01:45:25 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 17 Jan 2020 06:45:25 +0000
Subject: [issue38840] incorrect __all__ list in multiprocessing.managers module
In-Reply-To: <1574115502.48.0.329816372934.issue38840@roundup.psfhosted.org>
Message-ID: <1579243525.95.0.705899211033.issue38840@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38840>
_______________________________________

From report at bugs.python.org  Fri Jan 17 01:52:35 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 17 Jan 2020 06:52:35 +0000
Subject: [issue27540] msvcrt.ungetwch() calls _ungetch()
In-Reply-To: <1468745012.08.0.321893951317.issue27540@psf.upfronthosting.co.za>
Message-ID: <1579243955.67.0.838999643731.issue27540@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

Python 2 is EOL, so I think this issue should be closed.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27540>
_______________________________________

From report at bugs.python.org  Fri Jan 17 02:54:57 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Fri, 17 Jan 2020 07:54:57 +0000
Subject: [issue39349] Add "cancel_futures" parameter to
 concurrent.futures.Executor.shutdown()
In-Reply-To: <1579147714.25.0.252393666546.issue39349@roundup.psfhosted.org>
Message-ID: <1579247697.15.0.597484894102.issue39349@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> It was a bit more involved than I originally anticipated, as I had to make a minor change in the _worker() function to allow the new parameter to be compatible with wait (which is important, as it prevents dangling threads).

Never mind, I just realized that I could simply add work_queue.put(None) at the end of the queue drain to unblock the indefinitely hanging thread. So, the global constant and change in logic for _worker() isn't needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39349>
_______________________________________

From report at bugs.python.org  Fri Jan 17 03:13:58 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 17 Jan 2020 08:13:58 +0000
Subject: [issue39364] Automatically tabulate module contents in the docs
In-Reply-To: <1579212346.83.0.45042082539.issue39364@roundup.psfhosted.org>
Message-ID: <1579248838.26.0.250815029864.issue39364@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39364>
_______________________________________

From report at bugs.python.org  Fri Jan 17 04:11:15 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 17 Jan 2020 09:11:15 +0000
Subject: [issue39366] Remove deprecated nntplib method
Message-ID: <1579252275.31.0.83759168902.issue39366@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

Remove deprecated methods since Python 3.3.
Moreover nntplib.NNTP.xgtitle has not been exposed through docs.python.org
https://docs.python.org/3/library/nntplib.html

----------
assignee: corona10
messages: 360163
nosy: corona10, vstinner
priority: normal
severity: normal
status: open
title: Remove deprecated nntplib method
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39366>
_______________________________________

From report at bugs.python.org  Fri Jan 17 04:15:57 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 17 Jan 2020 09:15:57 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1579252557.48.0.214562974569.issue39336@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17431
pull_request: https://github.com/python/cpython/pull/18035

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Fri Jan 17 04:16:53 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 17 Jan 2020 09:16:53 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1579252613.01.0.181267332078.issue39336@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests:  -17431

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Fri Jan 17 04:17:08 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 17 Jan 2020 09:17:08 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1579252628.01.0.969759644576.issue39336@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17433
pull_request: https://github.com/python/cpython/pull/18035

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Fri Jan 17 04:17:07 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 17 Jan 2020 09:17:07 +0000
Subject: [issue39366] Remove deprecated nntplib method
In-Reply-To: <1579252275.31.0.83759168902.issue39366@roundup.psfhosted.org>
Message-ID: <1579252627.9.0.719418192978.issue39366@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17432
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18035

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39366>
_______________________________________

From report at bugs.python.org  Fri Jan 17 04:18:35 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 17 Jan 2020 09:18:35 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1579252715.46.0.446216091904.issue39336@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests:  -17433

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Fri Jan 17 04:19:58 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 17 Jan 2020 09:19:58 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1579252798.83.0.227152341486.issue39336@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I apologize for the noise caused by the wrong PR connection.

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Fri Jan 17 04:59:24 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 17 Jan 2020 09:59:24 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579255164.98.0.94552237661.issue32615@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

This is duplicate of #1402289, which was rejected.

I agree with Victor.  Python should be free to optimize namespace access.

Namespace access is an implementation detail and user should not assume such "consistency" here.  It is like this:

  x = 1000
  y = x - 1 + 1
  print(x is y)  # True or False, it's implementation detail.


It seems inconsistent for some people, but there are some areas people shouldn't assume consistency.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Fri Jan 17 05:09:18 2020
From: report at bugs.python.org (yang)
Date: Fri, 17 Jan 2020 10:09:18 +0000
Subject: [issue38921] Max Recursion Depth Reached in Logging Library
In-Reply-To: <1574793583.29.0.769726111814.issue38921@roundup.psfhosted.org>
Message-ID: <1579255758.48.0.40469177781.issue38921@roundup.psfhosted.org>


yang <fhsxfhsx at 126.com> added the comment:

You assigned a handler to a variable `formatter`, and then called `setFormatter(formatter)`, but `formatter` is in fact a handler. The two classes `Formatter` and `Handler` happen to have a same name method `format` which is called when logging. So what happend is the logger wants to format your logging string, and it calls its handlers' `format` method. And in this handler's `format` method, the handler calls its formatter's `format` method, which ends to be another handler rather than a real formatter. And you repeated it 1000 times, which caused a 1000-level nested recursion.

----------
nosy: +fhsxfhsx

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38921>
_______________________________________

From report at bugs.python.org  Fri Jan 17 05:27:10 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Fri, 17 Jan 2020 10:27:10 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579256830.88.0.910398560463.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

Absolutely should be able to optimize namespace access. The fact that namespace is a dict is an implementation detail, it's still inefficient even with all those version counters and inline caches. Ironically, to let people prototype better, more efficient ways to deal with namespace access, it should be possible to override an object used as a namespace. Thanks for making that much more complicated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Fri Jan 17 05:27:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 17 Jan 2020 10:27:36 +0000
Subject: [issue39357] bz2: Remove deprecated buffering parameter of bz2.BZ2File
In-Reply-To: <1579170165.88.0.778090338845.issue39357@roundup.psfhosted.org>
Message-ID: <1579256856.68.0.472565732508.issue39357@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

https://github.com/python/cpython/blob/9baf242fc733ab8a52a0b6201d95c6fdb8251745/Lib/bz2.py#L50 contains similar reference about buffering parameter deprecation like bz2.rst which could also be removed. Thanks.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39357>
_______________________________________

From report at bugs.python.org  Fri Jan 17 06:04:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 11:04:52 +0000
Subject: [issue39366] Remove deprecated nntplib method
In-Reply-To: <1579252275.31.0.83759168902.issue39366@roundup.psfhosted.org>
Message-ID: <1579259092.39.0.504224424763.issue39366@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm not used to the NNTP protocol. Does the news.gmane.io support these 2 extensions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39366>
_______________________________________

From report at bugs.python.org  Fri Jan 17 06:17:46 2020
From: report at bugs.python.org (Horace Stoica)
Date: Fri, 17 Jan 2020 11:17:46 +0000
Subject: [issue39367] readline module core dumps Python 3.8.1 when calling
 exit()
Message-ID: <1579259866.32.0.542672703415.issue39367@roundup.psfhosted.org>


New submission from Horace Stoica <fhstoica at gmail.com>:

Built Python 3.8.1 from source on Fedora 30:

kernel: 5.1.8-300.fc30.x86_64

Python 3.8.1 (default, Jan 15 2020, 08:49:34)
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux

Installed the readline module as the arrows do not work when running Python interactively.

~/local/bin/pip3.8 install readline
Collecting readline
  Using cached https://files.pythonhosted.org/packages/f4/01/2cf081af8d880b44939a5f1b446551a7f8d59eae414277fd0c303757ff1b/readline-6.2.4.1.tar.gz

However, after installing readline Python core-dumps on Crtl+D or exit():

>>> exit()
munmap_chunk(): invalid pointer
Aborted (core dumped)

I uninstalled the readline module and now it no longer core dumps.

----------
components: Extension Modules
messages: 360170
nosy: fhstoica
priority: normal
severity: normal
status: open
title: readline module core dumps Python 3.8.1 when calling exit()
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39367>
_______________________________________

From report at bugs.python.org  Fri Jan 17 06:29:00 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 17 Jan 2020 11:29:00 +0000
Subject: [issue39367] readline module core dumps Python 3.8.1 when calling
 exit()
In-Reply-To: <1579259866.32.0.542672703415.issue39367@roundup.psfhosted.org>
Message-ID: <1579260540.19.0.365921632843.issue39367@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

> Installed the readline module as the arrows do not work when running Python interactively.

This is not a suggested way to fix the issue, especially given that the module you installed is marked as deprecated: https://pypi.org/project/readline/

> Built Python 3.8.1 from source on Fedora 30:

Instead, when you compile, look for a line like this

    Failed to find the necessary bits to build these modules:
    ...
    readline

or

    Failed to build these modules:
    ...
    readline

and then scan through the build log to either find the compiler error or you're most probably missing a dependency like readline-devel

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39367>
_______________________________________

From report at bugs.python.org  Fri Jan 17 06:59:42 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 17 Jan 2020 11:59:42 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579262382.73.0.389151198241.issue32615@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Ironically, to let people prototype better, more efficient ways to deal with namespace access, it should be possible to override an object used as a namespace.

You can benchmark your prototype namespace object by regular Python code:

  d["name"]  # LOAD_GLOBAL
  d["name"] = 1  # STORE_GLOBAL

So I don't think no overriding blocks prototyping.


On the other hand, allowing overriding makes future optimizations difficult.  For example:

```
>>> import dis
>>> def counter():
...     global _cnt
...     _cnt += 1
...     return _cnt
...
>>> dis.dis(counter)
  3           0 LOAD_GLOBAL              0 (_cnt)
              2 LOAD_CONST               1 (1)
              4 INPLACE_ADD
              6 STORE_GLOBAL             0 (_cnt)

  4           8 LOAD_GLOBAL              0 (_cnt)
             10 RETURN_VALUE
```

We may be possible to replace bytecode from `STORE_GLOBAL _cnt; LOAD_GLOBAL _cnt` into `DUP_TOP; STORE_GLOBAL _cnt`.

If we guarantee namespace overriding, it's very easy to break the guarantee while such optimization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:01:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 12:01:14 +0000
Subject: [issue39367] readline module core dumps Python 3.8.1 when calling
 exit()
In-Reply-To: <1579259866.32.0.542672703415.issue39367@roundup.psfhosted.org>
Message-ID: <1579262474.14.0.663502878739.issue39367@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm able to reproduce the issue on Fedora 31, but only if the 3rd party readline module is loaded, instead of the stdlib "readline" module.

The problem is that https://pypi.org/project/readline/ misuses the Python memory allocator API. The GIL must be held to call PyMem_Malloc(). This project should be modified to use PyMem_RawMalloc().

https://docs.python.org/dev/c-api/memory.html#raw-memory-interface
vs
https://docs.python.org/dev/c-api/memory.html#memory-interface

It's a bug in a 3rd party module, I close the issue.


== packaged Python 3.8 ==

vstinner at apu$ python3.8 -m pip install --user readline

Python still uses the stdlib module by default (sys.path order):

vstinner at apu$ python3.8 
Python 3.8.1 (default, Dec 19 2019, 00:00:00) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
>>> readline
<module 'readline' from '/usr/lib64/python3.8/lib-dynload/readline.cpython-38-x86_64-linux-gnu.so'>

I'm using uninstall just to know the path, but then cancel:

vstinner at apu$ python3.8 -m pip uninstall readline
Uninstalling readline-6.2.4.1:
  Would remove:
    /home/vstinner/.local/lib/python3.8/site-packages/readline-6.2.4.1-py3.8.egg-info
    /home/vstinner/.local/lib/python3.8/site-packages/readline.cpython-38-x86_64-linux-gnu.so
Proceed (y/n)? n

I reproduce the issue if I force to prefer the 3rd party readline:

vstinner at apu$ PYTHONPATH=/home/vstinner/.local/lib/python3.8/site-packages/ python3.8 
Python 3.8.1 (default, Dec 19 2019, 00:00:00) 
[GCC 9.2.1 20190827 (Red Hat 9.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import readline
munmap_chunk(): invalid pointer
Abandon (core dumped)

== Python 3.9 compiled manually in debug mode ==

(...)
vstinner at apu$ PYTHONPATH=/home/vstinner/python/master/env/lib/python3.9/site-packages/ gdb -args env/bin/python 
GNU gdb (GDB) Fedora 8.3.50.20190824-26.fc31
(gdb) run

>>> import readline
Fatal Python error: Python memory allocator called without holding the GIL
Python runtime state: initialized

Current thread 0x00007ffff7c1f740 (most recent call first):
<no Python frame>

Program received signal SIGABRT, Aborted.
0x00007ffff7c60625 in raise () from /lib64/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install libxcrypt-4.4.10-2.fc31.x86_64 ncurses-libs-6.1-12.20190803.fc31.x86_64
(gdb) where
#0  0x00007ffff7c60625 in raise () from /lib64/libc.so.6
#1  0x00007ffff7c498d9 in abort () from /lib64/libc.so.6
#2  0x0000000000560b43 in fatal_error (prefix=0x0, msg=0x6b4c40 "Python memory allocator called without holding the GIL", status=-1) at Python/pylifecycle.c:2249
#3  0x0000000000560b6f in Py_FatalError (msg=0x6b4c40 "Python memory allocator called without holding the GIL") at Python/pylifecycle.c:2259
#4  0x000000000047d988 in _PyMem_DebugCheckGIL () at Objects/obmalloc.c:2320
#5  0x000000000047d9a0 in _PyMem_DebugMalloc (ctx=0x7cd950 <_PyMem_Debug+48>, nbytes=17) at Objects/obmalloc.c:2328
#6  0x000000000047b958 in PyMem_Malloc (size=17) at Objects/obmalloc.c:605
#7  0x00007fffeaa48dc0 in call_readline (sys_stdin=0x7ffff7de67e0 <_IO_2_1_stdin_>, sys_stdout=0x7ffff7de7500 <_IO_2_1_stdout_>, prompt=0x7fffeaa9c480 ">>> ")
    at Modules/3.x/readline.c:1122
#8  0x000000000069e8a4 in PyOS_Readline (sys_stdin=0x7ffff7de67e0 <_IO_2_1_stdin_>, sys_stdout=0x7ffff7de7500 <_IO_2_1_stdout_>, prompt=0x7fffeaa9c480 ">>> ")
    at Parser/myreadline.c:358
#9  0x0000000000615155 in tok_nextc (tok=0x988f00) at Parser/tokenizer.c:848
#10 0x0000000000615f7d in tok_get (tok=0x988f00, p_start=0x7fffffffd118, p_end=0x7fffffffd110) at Parser/tokenizer.c:1128
#11 0x0000000000617876 in PyTokenizer_Get (tok=0x988f00, p_start=0x7fffffffd118, p_end=0x7fffffffd110) at Parser/tokenizer.c:1774
#12 0x0000000000612862 in parsetok (tok=0x988f00, g=0x7f1ce0 <_PyParser_Grammar>, start=256, err_ret=0x7fffffffd280, flags=0x7fffffffd27c) at Parser/parsetok.c:251
#13 0x0000000000612672 in PyParser_ParseFileObject (fp=0x7ffff7de67e0 <_IO_2_1_stdin_>, filename='<stdin>', enc=0x7fffeab24340 "utf-8", g=0x7f1ce0 <_PyParser_Grammar>, start=256, 
    ps1=0x7fffeaa9c480 ">>> ", ps2=0x7fffeaa9c520 "... ", err_ret=0x7fffffffd280, flags=0x7fffffffd27c) at Parser/parsetok.c:186
#14 0x0000000000567716 in PyParser_ASTFromFileObject (fp=0x7ffff7de67e0 <_IO_2_1_stdin_>, filename='<stdin>', enc=0x7fffeab24340 "utf-8", start=256, ps1=0x7fffeaa9c480 ">>> ", 
    ps2=0x7fffeaa9c520 "... ", flags=0x7fffffffd470, errcode=0x7fffffffd314, arena=0x7fffeab2d7c0) at Python/pythonrun.c:1387
#15 0x0000000000564fc1 in PyRun_InteractiveOneObjectEx (fp=0x7ffff7de67e0 <_IO_2_1_stdin_>, filename='<stdin>', flags=0x7fffffffd470) at Python/pythonrun.c:239
#16 0x0000000000564cbd in PyRun_InteractiveLoopFlags (fp=0x7ffff7de67e0 <_IO_2_1_stdin_>, filename_str=0x69f43a "<stdin>", flags=0x7fffffffd470) at Python/pythonrun.c:121
#17 0x0000000000564b80 in PyRun_AnyFileExFlags (fp=0x7ffff7de67e0 <_IO_2_1_stdin_>, filename=0x69f43a "<stdin>", closeit=0, flags=0x7fffffffd470) at Python/pythonrun.c:80
#18 0x000000000041e910 in pymain_run_stdin (config=0x819240, cf=0x7fffffffd470) at Modules/main.c:467
#19 0x000000000041ec10 in pymain_run_python (exitcode=0x7fffffffd4bc) at Modules/main.c:556
#20 0x000000000041ece6 in Py_RunMain () at Modules/main.c:632
#21 0x000000000041ed60 in pymain_main (args=0x7fffffffd520) at Modules/main.c:662
#22 0x000000000041edda in Py_BytesMain (argc=1, argv=0x7fffffffd648) at Modules/main.c:686
#23 0x000000000041d796 in main (argc=1, argv=0x7fffffffd648) at ./Programs/python.c:16

----------
nosy: +vstinner
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39367>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:03:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 12:03:01 +0000
Subject: [issue39357] bz2: Remove deprecated buffering parameter of bz2.BZ2File
In-Reply-To: <1579170165.88.0.778090338845.issue39357@roundup.psfhosted.org>
Message-ID: <1579262581.6.0.0975732695375.issue39357@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17434
pull_request: https://github.com/python/cpython/pull/18036

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39357>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:08:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 12:08:49 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579262929.58.0.570486149176.issue32615@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

As explained multiple times, this feature request is rejected. I close the issue.

Paul: Your behavior is not appropriate and violates the Python code of conduct. You have already been warned by Pablo.

----------
resolution:  -> rejected
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:12:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 12:12:51 +0000
Subject: [issue39367] readline module core dumps Python 3.8.1 when calling
 exit()
In-Reply-To: <1579259866.32.0.542672703415.issue39367@roundup.psfhosted.org>
Message-ID: <1579263171.68.0.842206242561.issue39367@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh right, Ammar is right, you miss a dependency. Try maybe:

sudo dnf install -y dnf-plugins-core
sudo dnf builddep -y python3

https://cpython-core-tutorial.readthedocs.io/en/latest/build_cpython_linux.html

... but why are you building Python from source? Fedora provides python3.8 ;-) At least, on Fedora 31, Python 3.8 and 3.9 are packaged ;-)

If you built it to contribute to Python, that's great!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39367>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:28:51 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 17 Jan 2020 12:28:51 +0000
Subject: [issue27379] SocketType changed in Python 3
In-Reply-To: <1466738397.82.0.0999219877747.issue27379@psf.upfronthosting.co.za>
Message-ID: <1579264131.27.0.903323982275.issue27379@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions: +Python 3.8, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27379>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:33:41 2020
From: report at bugs.python.org (Horace Stoica)
Date: Fri, 17 Jan 2020 12:33:41 +0000
Subject: [issue39367] readline module core dumps Python 3.8.1 when calling
 exit()
In-Reply-To: <1579259866.32.0.542672703415.issue39367@roundup.psfhosted.org>
Message-ID: <1579264421.72.0.823291683334.issue39367@roundup.psfhosted.org>


Horace Stoica <fhstoica at gmail.com> added the comment:

A big "thank you" to everyone, I installed readline-develop and rebuilt from source, and now the problem is fixed.

The reason I am building from source is that Fedora 30 provides Python 3.7.3 and I wanted to try out the new features (like the walrus operator) that were introduced in version 3.8.

I hope to get to the point of contributing to Python itself, for now I am looking mainly at extending Python with C++ and embedding Python in C++ applications. 

Thanks again, 
Horace

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39367>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:34:56 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Fri, 17 Jan 2020 12:34:56 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579264496.86.0.784106239026.issue32615@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> We may be possible to replace bytecode from `STORE_GLOBAL _cnt; LOAD_GLOBAL _cnt` into `DUP_TOP; STORE_GLOBAL _cnt`.

Sounds good, and that's why I personally care about the "STORE" case, and the patch I submit touches only it, which would affect only cases when explicit "global var" declarations are used, which aren't frequent. I definitely would be too shy to submit a patch for more LOAD_* cases, though I may image why people may want that still.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:36:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 12:36:11 +0000
Subject: [issue39367] readline module core dumps Python 3.8.1 when calling
 exit()
In-Reply-To: <1579259866.32.0.542672703415.issue39367@roundup.psfhosted.org>
Message-ID: <1579264571.61.0.72107076477.issue39367@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The reason I am building from source is that Fedora 30 provides Python 3.7.3 and I wanted to try out the new features (like the walrus operator) that were introduced in version 3.8.

Did you try "dnf install python38"? It's available on Fedora 30. FYI I'm part of the package maintainers of Python packages on Fedora and RHEL ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39367>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:42:52 2020
From: report at bugs.python.org (Horace Stoica)
Date: Fri, 17 Jan 2020 12:42:52 +0000
Subject: [issue39367] readline module core dumps Python 3.8.1 when calling
 exit()
In-Reply-To: <1579259866.32.0.542672703415.issue39367@roundup.psfhosted.org>
Message-ID: <1579264972.3.0.834403927676.issue39367@roundup.psfhosted.org>


Horace Stoica <fhstoica at gmail.com> added the comment:

Tried dnf install python38 and it works. Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39367>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:50:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 12:50:43 +0000
Subject: [issue39357] bz2: Remove deprecated buffering parameter of bz2.BZ2File
In-Reply-To: <1579170165.88.0.778090338845.issue39357@roundup.psfhosted.org>
Message-ID: <1579265443.14.0.434540212072.issue39357@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 10fd6b2b9f0aeb8f5a0ce4cb4b9f21f942d39a71 by Victor Stinner in branch 'master':
bpo-39357: Update bz2 docstring: remove buffering (GH-18036)
https://github.com/python/cpython/commit/10fd6b2b9f0aeb8f5a0ce4cb4b9f21f942d39a71


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39357>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:50:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 12:50:58 +0000
Subject: [issue39357] bz2: Remove deprecated buffering parameter of bz2.BZ2File
In-Reply-To: <1579170165.88.0.778090338845.issue39357@roundup.psfhosted.org>
Message-ID: <1579265458.98.0.290201758252.issue39357@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Karthikeyan, I forgot about the docstring.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39357>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:55:23 2020
From: report at bugs.python.org (Jaap Woldringh)
Date: Fri, 17 Jan 2020 12:55:23 +0000
Subject: [issue39368] A matrix (list of lists) behaves differently,
 depending how it is created
Message-ID: <1579265723.61.0.0732366373577.issue39368@roundup.psfhosted.org>


New submission from Jaap Woldringh <jjhwoldringh at ziggo.nl>:

Python used:
Python 3.6.9 (default, Nov  7 2019, 10:44:02) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
In Ubuntu 18.04.3

But in any other version of Python3, and Python2,  that I tried, the behaviour of a (square) matrix depends on how it is created; as I can demonstrate in a test program matrix_experiment.py that is attached to this report.

1. it behaves as expected when created by entering all it?s elements like so:
A = [[ 1,2,3],[1,2,3],[1,2,3]]

2. If it is created by appending predefined rows, it behaves as if all rows are the same as the last row:
row = [1,2,3]
B=[]
for i in range(3):
    B.appends(row)

The result matrix is the same as A:   [[1, 2, 3], [1, 2, 3], [1, 2, 3]]

Both results are equal:

print(A==B) gives True.

But when using B the result is disastrous as the attached matrix_experiment.py
program shows.

I consider this a very serious bug, and first filed it at Ubuntu?s Launchpad, but I don't find it there.
So now I file this again, at Python.org itself, using my new account.

----------
components: Tests
files: matrix_experiment.py
messages: 360182
nosy: jjhwoldringh
priority: normal
severity: normal
status: open
title: A matrix (list of lists) behaves differently, depending how it is created
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48849/matrix_experiment.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39368>
_______________________________________

From report at bugs.python.org  Fri Jan 17 07:58:51 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 17 Jan 2020 12:58:51 +0000
Subject: [issue39357] bz2: Remove deprecated buffering parameter of bz2.BZ2File
In-Reply-To: <1579170165.88.0.778090338845.issue39357@roundup.psfhosted.org>
Message-ID: <1579265931.97.0.544034488923.issue39357@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the fix Victor :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39357>
_______________________________________

From report at bugs.python.org  Fri Jan 17 08:03:07 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 17 Jan 2020 13:03:07 +0000
Subject: [issue39368] A matrix (list of lists) behaves differently,
 depending how it is created
In-Reply-To: <1579265723.61.0.0732366373577.issue39368@roundup.psfhosted.org>
Message-ID: <1579266187.79.0.582557597002.issue39368@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

You're referencing to the same list 3 times in B. So modifying it once means all the elements referring to same object reflect the change. Make a copy of the list during append to ensure modification of one doesn't affect other. This is not a python bug.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39368>
_______________________________________

From report at bugs.python.org  Fri Jan 17 08:08:29 2020
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jan 2020 13:08:29 +0000
Subject: [issue39368] A matrix (list of lists) behaves differently,
 depending how it is created
In-Reply-To: <1579265723.61.0.0732366373577.issue39368@roundup.psfhosted.org>
Message-ID: <1579266509.39.0.979996714325.issue39368@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See also https://docs.python.org/3/faq/programming.html#why-did-changing-list-y-also-change-list-x

You can use the builtin function id() to see the id of the lists, and verify whether they refer to the same object or not.

----------
nosy: +ezio.melotti
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39368>
_______________________________________

From report at bugs.python.org  Fri Jan 17 08:41:51 2020
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Fri, 17 Jan 2020 13:41:51 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1579268511.14.0.413355873821.issue39165@roundup.psfhosted.org>


Juancarlo A?ez <apalala at gmail.com> added the comment:

The analysis done by Terry bypasses the fact that `search(...)` returns `None` when there is no match, so indexing or calling methods in its result is not safe code. 

`findall()` returns an empty list when there is no match.

`findalliter()` returns an empty iterator when there is no match.

`findfirst()` may return a `default` value when there is no match.

If `search()` is proposed to replace `findall()[0]`, then the idiom has to be (depending on the case):

m[0] if (m := re.search(...)) else '0'
m.groups() if (m := re.search(...)) else '0'

In contrast, `findfirst()` returns a value that is the same as `findall()` when there is a match, or a `default` if there is no match.

m[0] if (m := re.findall(...)) else '0'

Compare with:

findfirst(..., default='0')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39165>
_______________________________________

From report at bugs.python.org  Fri Jan 17 08:46:46 2020
From: report at bugs.python.org (=?utf-8?q?Juancarlo_A=C3=B1ez?=)
Date: Fri, 17 Jan 2020 13:46:46 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1579268806.15.0.442402632869.issue39165@roundup.psfhosted.org>


Juancarlo A?ez <apalala at gmail.com> added the comment:

The bottom problem, as I see it, is that, historically, `re.search()` returns `None` when there is no match, instead of returning a `Match` object that is consistent with "no match" (evaluates to `False`, etc.)

The above seems too difficult to repair as so much existing code relies on those semantics (`if match is None` is the risky bit). 

Hence, `findall()`, `findalliter()`, and `findfirst()`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39165>
_______________________________________

From report at bugs.python.org  Fri Jan 17 08:48:18 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 17 Jan 2020 13:48:18 +0000
Subject: [issue39366] Remove deprecated nntplib method
In-Reply-To: <1579252275.31.0.83759168902.issue39366@roundup.psfhosted.org>
Message-ID: <1579268898.43.0.198973775229.issue39366@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Looks like xgtitle is supported but xpath is not.

>>> a.xgtitle('gmane.comp.python.committers')
('282 Descriptions in form "group description"', [('gmane.comp.python.committers', 'CPython Committers (non-public) (Moderated)')])
>>> a.xpath(message_id)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/nntplib.py", line 865, in xpath
    resp = self._shortcmd('XPATH {0}'.format(id))
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/nntplib.py", line 513, in _shortcmd
    return self._getresp()
  File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/nntplib.py", line 458, in _getresp
    raise NNTPPermanentError(resp)
nntplib.NNTPPermanentError: 500 What?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39366>
_______________________________________

From report at bugs.python.org  Fri Jan 17 08:52:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Jan 2020 13:52:55 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1579269175.82.0.632596010838.issue39165@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Most of examples do not test whether findall() returns an empty list. So there is no significant difference with using search() -- just different type of exception if fails (IndexError, TypeError or AttributeError). Since most examples do not handle errors, this will only affect a traceback if you use the script improperly.

If it is important to you, you can write (re.search(...) or [])[0] and get the same IndexError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39165>
_______________________________________

From report at bugs.python.org  Fri Jan 17 08:53:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 13:53:18 +0000
Subject: [issue39366] Remove deprecated nntplib method
In-Reply-To: <1579252275.31.0.83759168902.issue39366@roundup.psfhosted.org>
Message-ID: <1579269198.19.0.673732419803.issue39366@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

>>> a.xgtitle('gmane.comp.python.committers')
('282 Descriptions in form "group description"', [('gmane.comp.python.committers', 'CPython Committers (non-public) (Moderated)')])

Does https://docs.python.org/dev/library/nntplib.html#nntplib.NNTP.description give the same result?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39366>
_______________________________________

From report at bugs.python.org  Fri Jan 17 08:55:27 2020
From: report at bugs.python.org (Wellington PF)
Date: Fri, 17 Jan 2020 13:55:27 +0000
Subject: [issue39369] Doc: Update mmap readline method documentation
Message-ID: <1579269327.81.0.0431905682961.issue39369@roundup.psfhosted.org>


New submission from Wellington PF <wellpardim10 at gmail.com>:

Update mmap readline method description. The fact that the readline method does update the file position should not be ignored since this might give the impression for the programmer that it doesn't update it.

----------
assignee: docs at python
components: Documentation
messages: 360191
nosy: docs at python, wellpardim
priority: normal
pull_requests: 17435
severity: normal
status: open
title: Doc: Update mmap readline method documentation
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39369>
_______________________________________

From report at bugs.python.org  Fri Jan 17 09:11:24 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 17 Jan 2020 14:11:24 +0000
Subject: [issue39366] Remove deprecated nntplib method
In-Reply-To: <1579252275.31.0.83759168902.issue39366@roundup.psfhosted.org>
Message-ID: <1579270284.48.0.935113120728.issue39366@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> Does https://docs.python.org/dev/library/nntplib.html#nntplib.NNTP.description give the same result?

Not exactly same but descriptions give a similar result.

>>> import nntplib
>>> a = nntplib.NNTP('news.gmane.io')
>>> a.description('gmane.comp.python.committers')
'CPython Committers (non-public) (Moderated)'
>>> a.descriptions('gmane.comp.python.committers')
('215 Newsgroup descriptions in form "group description"', {'gmane.comp.python.committers': 'CPython Committers (non-public) (Moderated)'})
>>> a.xgtitle('gmane.comp.python.committers')
<stdin>:1: DeprecationWarning: The XGTITLE extension is not actively used, use descriptions() instead
('282 Descriptions in form "group description"', [('gmane.comp.python.committers', 'CPython Committers (non-public) (Moderated)')])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39366>
_______________________________________

From report at bugs.python.org  Fri Jan 17 09:17:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 14:17:56 +0000
Subject: [issue39356] zipfile suprising "except DeprecationWarning:" block
In-Reply-To: <1579167493.26.0.213163602183.issue39356@roundup.psfhosted.org>
Message-ID: <1579270676.7.0.663037576811.issue39356@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1d3b0aaa54c56282c0a3e7fc396e5b1de8b1974e by Victor Stinner in branch 'master':
bpo-39356, zipfile: Remove code handling DeprecationWarning (GH-18027)
https://github.com/python/cpython/commit/1d3b0aaa54c56282c0a3e7fc396e5b1de8b1974e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39356>
_______________________________________

From report at bugs.python.org  Fri Jan 17 09:18:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 14:18:29 +0000
Subject: [issue39356] zipfile suprising "except DeprecationWarning:" block
In-Reply-To: <1579167493.26.0.213163602183.issue39356@roundup.psfhosted.org>
Message-ID: <1579270709.95.0.535449300438.issue39356@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39356>
_______________________________________

From report at bugs.python.org  Fri Jan 17 09:23:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Jan 2020 14:23:34 +0000
Subject: [issue39353] Deprecate the binhex module
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579271014.05.0.166319641237.issue39353@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Fri Jan 17 09:47:07 2020
From: report at bugs.python.org (Dreas Nielsen)
Date: Fri, 17 Jan 2020 14:47:07 +0000
Subject: [issue39370] askopenfilename is missing from the Tkinter filedialog
 library in 2.7.17
Message-ID: <1579272427.57.0.817870554676.issue39370@roundup.psfhosted.org>


New submission from Dreas Nielsen <dreas.nielsen at gmail.com>:

In Python 2.7.17 on Linux, the code:

    import tkinter.filedialog as tkfiledialog
    dir(tkfiledialog.askopenfilename)

results in:

    AttributeError: 'module' object has no attribute 'askopenfilename'

Any attempt to use 'askopenfilename' has the same result, of course.

----------
components: Tkinter
messages: 360194
nosy: rdnielsen
priority: normal
severity: normal
status: open
title: askopenfilename is missing from the Tkinter filedialog library in 2.7.17
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39370>
_______________________________________

From report at bugs.python.org  Fri Jan 17 10:13:06 2020
From: report at bugs.python.org (Jaap Woldringh)
Date: Fri, 17 Jan 2020 15:13:06 +0000
Subject: [issue39368] A matrix (list of lists) behaves differently,
 depending how it is created
In-Reply-To: <1579266187.79.0.582557597002.issue39368@roundup.psfhosted.org>
Message-ID: <ebb9ee10-0f30-1706-eb8d-7edc0332ace0@ziggo.nl>


Jaap Woldringh <jjhwoldringh at ziggo.nl> added the comment:

Op 17-01-2020 om 14:03 schreef Karthikeyan Singaravelan:
> Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:
>
> You're referencing to the same list 3 times in B. So modifying it once means all the elements referring to same object reflect the change. Make a copy of the list during append to ensure modification of one doesn't affect other. This is not a python bug.
>
> ----------
> nosy: +xtreak
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39368>
> _______________________________________

Ah, I see! Thank you for pointing this out to me! I have been pondering 
this for days on end on what was happening here.

This behaviour of Python is very frustrating, and even if "it is not a 
bug" (I knew it!) it's very nasty, and shouldn't be. Your suggestion of 
making a copy of the list during the append saves my day! And Python itself!

I was creating a very simple program for encrypting a sentence using a 
square matrix, and expected a one hour job at most. It became days, and 
I finally created a very simple method, without a rxk matrix itself, but 
using the idea!

So, if possible, please, improve Python so that this feature doesn't 
cause these unnecessary problems. Meanwhile I retract my bug report!

To my opinion this feature of Python, having aparently same objects 
refer to the same addresses in memory, was useful in times long ago when 
memory was expensive. But now this feature is not feature at all. To my 
opinion :)

Gtsori menf egr

Jaap Woldringh

----------
Added file: https://bugs.python.org/file48850/code.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39368>
_______________________________________
-------------- next part --------------
### een nieuwe wijze van coderen met behulp
### van een denkbeeldige vierkante matrix
###
def codeertekst(tekst):
    lengte = len(tekst)
    # bepalen dimensie vierkante matrix
    j=1
    while j*j<lengte:
        j+=1
    # lengte tekst aanvullen tot j*j matrix
    # met spaties.
    tekst+=(j*j-lengte)*" "
    # nieuwe even lange tekst aanmaken
    codetekst=tekst

    # lists maken van beide teksten
    # omdat strings immutable zijn en lists niet.
    tekst=list(tekst)
    codetekst=list(codetekst)
    
    # de eigenlijke codering: in de denkbeeldige
    # vierkante matrix rijen en kolommen verwisselen
    # je kunt dit het beste zien door twee j x j matrices
    # te tekenen en in te vullen op papier met korte tekst
    for r in range(j):
        for k in range(j):
            codetekst[r*j+k] = tekst[r+k*j]     ## THIS IS WHERE THE MAGIC IS!

    # conversie lijst van karakters codetekst naar
    # de string code.       
    code=""
    for i in range(j*j):
        code += codetekst[i]
                
    return code         # de gecodeerde tekst
    
def invoer():
    tekst = input("Tekst, afsluiten met enter : ")
    
    return tekst        # de ingevoerde tekst
    
###
# programma dat dit gebruikt.
###
tekst = invoer()
code = codeertekst(tekst)
print(tekst)
print()
print (code)
print()

'''
Gebruik: (kan dus heen en terug, op dezelfde manier!)

jaap at bromo:~$ cd Bureaublad
jaap at bromo:~/Bureaublad$ python3 code.py 
Tekst, afsluiten met enter : Korte tekst.
Korte tekst.

Kek o s rtt te. 

jaap at bromo:~/Bureaublad$ python3 code.py 
Tekst, afsluiten met enter : Kek o s rtt te.
Kek o s rtt te.

Korte tekst.    

'''



From report at bugs.python.org  Fri Jan 17 10:21:32 2020
From: report at bugs.python.org (Chris Dent)
Date: Fri, 17 Jan 2020 15:21:32 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1579274492.64.0.766957137513.issue27657@roundup.psfhosted.org>


Chris Dent <chris.dent at gmail.com> added the comment:

Just to add to the list of places this is causing a regression. This has broken the target host determination routines in gabbi: https://github.com/cdent/gabbi/issues/277

While the original fix may have been strictly correct in some ways, it results in a terrible UX, and as several others have noted violated backwards compatibility.

----------
nosy: +Chris Dent

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27657>
_______________________________________

From report at bugs.python.org  Fri Jan 17 11:08:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 16:08:54 +0000
Subject: [issue39366] Remove deprecated nntplib method
In-Reply-To: <1579252275.31.0.83759168902.issue39366@roundup.psfhosted.org>
Message-ID: <1579277334.13.0.573287656426.issue39366@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

>>> a.description('gmane.comp.python.committers')
'CPython Committers (non-public) (Moderated)'
>>> a.descriptions('gmane.comp.python.committers')
('215 Newsgroup descriptions in form "group description"', {'gmane.comp.python.committers': 'CPython Committers (non-public) (Moderated)'})

Well, both results contain the same important string: 'CPython Committers (non-public) (Moderated)'. So I think that it's ok to drop xgtitle() as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39366>
_______________________________________

From report at bugs.python.org  Fri Jan 17 11:14:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 16:14:32 +0000
Subject: [issue27657] urlparse fails if the path is numeric
In-Reply-To: <1469908637.82.0.696114480311.issue27657@psf.upfronthosting.co.za>
Message-ID: <1579277672.55.0.131035845036.issue27657@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27657>
_______________________________________

From report at bugs.python.org  Fri Jan 17 11:19:49 2020
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 17 Jan 2020 16:19:49 +0000
Subject: [issue27540] msvcrt.ungetwch() calls _ungetch()
In-Reply-To: <1468745012.08.0.321893951317.issue27540@psf.upfronthosting.co.za>
Message-ID: <1579277989.0.0.301011785197.issue27540@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

If this isn't an issue in Python 3, I agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27540>
_______________________________________

From report at bugs.python.org  Fri Jan 17 11:21:17 2020
From: report at bugs.python.org (Arden)
Date: Fri, 17 Jan 2020 16:21:17 +0000
Subject: [issue39371] http.client.HTTPResponse raises IncompleteRead on
 chunked encoding
Message-ID: <1579278077.15.0.801446785359.issue39371@roundup.psfhosted.org>


New submission from Arden <olyx32 at gmail.com>:

http.client.HTTPResponse._readinto_chunked has two problems in python 3.8 - 3.9.

1. _safe_readinto assumes that self.fp.readinto(b) will read exactly len(b) bytes. This is not always true, especially in case of SSL traffic. But _safe_readinto raises IncompleteRead if less len(b) bytes was read.

So, _safe_readinto should be removed and substituted with self.fp.readinto

2. _readinto_chunked may lose chunked block boundary because of this line:
  self.chunk_left = 0
it should be changed to
  self.chunk_left = chunk_left - n
in order to self._get_chunk_left() be able to find real chunk boundary

Corrected function looks like this:
def _readinto_chunked(self, b):
    assert self.chunked != _UNKNOWN
    total_bytes = 0
    mvb = memoryview(b)
    try:
        while True:
            chunk_left = self._get_chunk_left()
            if chunk_left is None:
                return total_bytes

            if len(mvb) <= chunk_left:
                n = self.fp.readinto(mvb)
                self.chunk_left = chunk_left - n
                return total_bytes + n

            temp_mvb = mvb[:chunk_left]
            n = self.fp.readinto(temp_mvb)
            mvb = mvb[n:]
            total_bytes += n
            self.chunk_left = chunk_left - n

    except IncompleteRead:
        raise IncompleteRead(bytes(b[0:total_bytes]))

----------
components: Library (Lib)
messages: 360199
nosy: Arden
priority: normal
severity: normal
status: open
title: http.client.HTTPResponse raises IncompleteRead on chunked encoding
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39371>
_______________________________________

From report at bugs.python.org  Fri Jan 17 11:22:53 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 17 Jan 2020 16:22:53 +0000
Subject: [issue39308] Literal[True] prints as Literal[1] in some cases
In-Reply-To: <1578785715.62.0.203170094807.issue39308@roundup.psfhosted.org>
Message-ID: <1579278173.31.0.596857201371.issue39308@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39308>
_______________________________________

From report at bugs.python.org  Fri Jan 17 11:29:52 2020
From: report at bugs.python.org (Arden)
Date: Fri, 17 Jan 2020 16:29:52 +0000
Subject: [issue39371] http.client.HTTPResponse raises IncompleteRead on
 chunked encoding
In-Reply-To: <1579278077.15.0.801446785359.issue39371@roundup.psfhosted.org>
Message-ID: <1579278592.64.0.671219829087.issue39371@roundup.psfhosted.org>


Arden <olyx32 at gmail.com> added the comment:

Pythons 3.5-3.7 also have
  self.chunk_left = 0
in  _readinto_chunked

I think it's bug but I didn't check it thoroughly

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39371>
_______________________________________

From report at bugs.python.org  Fri Jan 17 11:31:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 16:31:51 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579278711.12.0.939721862309.issue39353@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Deprecate the binhex module -> Deprecate the binhex module, binhex4 and hexbin4 standards

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Fri Jan 17 11:32:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 16:32:19 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579278739.92.0.823590588995.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> If deprecate the binhex module, we perhaps should deprecate also binascii.b2a_hqx(), binascii.a2b_hqx(), binascii.rlecode_hqx(), binascii.rledecode_hqx() and binascii.crc_hqx().

Ok, let's do that. I updated the issue title and my PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Fri Jan 17 11:54:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 16:54:25 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579280065.74.0.685776328319.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Serhiy Storchaka asked:
https://github.com/python/cpython/pull/18025#issuecomment-575645748

"""
What is a benefit of deprecating it?

This module is a high-level interface to several functions in the binascii module. This is all macOS specific stuff, so you need to ask macOS experts. If this encoding no longer used in macOS, its support can be removed, with deprecating first. If there are no plans to remove, there is no reason to deprecate.
"""

The intent is to reduce the size of the standard library to reduce the maintenance burden of Python in general. The final goal is to remove the module. But that's a first step to check if there is still any user around. We should deprecate it for at least one cycle.

I understood that binhex4 and hexbin4 standards were used on Mac OS 9 but are no longer used on macOS, nor used anywhere else. See my first message.

Mac OS 9 is really outdated in 2020 and will likely be completly dead when Python 3.10 will be released (first Python release when we will be able to remove the module).

About the removal: I would like first write a PEP to propose a process to move old or unmaintained modules from the stdlib to PyPI. The "removal" would mean "move to PyPI" (but yeah, technically it would still be removed from the stdlib).

But I don't want to open a discuss on this hypothetical PEP *here* (I didn't write it yet :-D).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Fri Jan 17 12:01:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 17:01:15 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579280475.9.0.875502613485.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

BinHex format: https://en.wikipedia.org/wiki/BinHex

The question here is not only if binhex remains popular, but more generally if we want to continue to maintain it forever. Each module has a cost on the overall Python maintenance burden.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Fri Jan 17 12:47:14 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 17 Jan 2020 17:47:14 +0000
Subject: [issue39372] The header files in Include/ have many declarations with
 no definition
Message-ID: <1579283234.13.0.0884348783159.issue39372@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

There are many declarations that lack definitions in our header files that should be cleaned (linking against those symbols will fail so removing them should be safe if I am not missing something).

----------
components: Build
messages: 360204
nosy: pablogsal
priority: normal
severity: normal
status: open
title: The header files in Include/ have many declarations with no definition
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39372>
_______________________________________

From report at bugs.python.org  Fri Jan 17 12:48:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 17 Jan 2020 17:48:33 +0000
Subject: [issue39372] The header files in Include/ have many declarations with
 no definition
In-Reply-To: <1579283234.13.0.0884348783159.issue39372@roundup.psfhosted.org>
Message-ID: <1579283313.17.0.0903911633024.issue39372@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +17436
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18037

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39372>
_______________________________________

From report at bugs.python.org  Fri Jan 17 13:08:30 2020
From: report at bugs.python.org (William Woodruff)
Date: Fri, 17 Jan 2020 18:08:30 +0000
Subject: [issue29435] Allow to pass fileobj to is_tarfile
In-Reply-To: <1486132653.21.0.166387912558.issue29435@psf.upfronthosting.co.za>
Message-ID: <1579284510.27.0.837330723463.issue29435@roundup.psfhosted.org>


William Woodruff <william at yossarian.net> added the comment:

I'll take a stab at this. It looks like `Tarfile.open` takes an optional keyword that should make this straightforward.

----------
nosy: +yossarian

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29435>
_______________________________________

From report at bugs.python.org  Fri Jan 17 13:10:27 2020
From: report at bugs.python.org (Dino Viehland)
Date: Fri, 17 Jan 2020 18:10:27 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579284627.37.0.3789587927.issue38076@roundup.psfhosted.org>


Change by Dino Viehland <dinoviehland at gmail.com>:


----------
pull_requests: +17437
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/18038

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Fri Jan 17 13:12:09 2020
From: report at bugs.python.org (Dino Viehland)
Date: Fri, 17 Jan 2020 18:12:09 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579284729.5.0.804281092244.issue38076@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

https://github.com/python/cpython/pull/18038 is a partial fix for this.  I think it fixes the crash at shutdown, although I'm still seeing a hang on master on Linux which is different then earlier versions of Python.  I seem to have a really bogus stack trace when I attach to it so I'm not quite certain what's going on there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Fri Jan 17 14:09:31 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Fri, 17 Jan 2020 19:09:31 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579288171.95.0.200626172699.issue38076@roundup.psfhosted.org>


Change by Eddie Elizondo <eduardo.elizondorueda at gmail.com>:


----------
pull_requests: +17438
pull_request: https://github.com/python/cpython/pull/18039

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Fri Jan 17 14:10:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 17 Jan 2020 19:10:22 +0000
Subject: [issue39372] The header files in Include/ have many declarations with
 no definition
In-Reply-To: <1579283234.13.0.0884348783159.issue39372@roundup.psfhosted.org>
Message-ID: <1579288222.6.0.902560446876.issue39372@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Good catch!

All removals LGTM.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39372>
_______________________________________

From report at bugs.python.org  Fri Jan 17 14:10:34 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 17 Jan 2020 19:10:34 +0000
Subject: [issue39370] askopenfilename is missing from the Tkinter filedialog
 library in 2.7.17
In-Reply-To: <1579272427.57.0.817870554676.issue39370@roundup.psfhosted.org>
Message-ID: <1579288234.35.0.401950584185.issue39370@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

In Python 2, askopenfilename was in the separate tkFileDialog module:

>>> import tkFileDialog
>>> dir(tkFileDialog.askopenfilename)
['__call__',  ...

https://docs.python.org/2/library/tkinter.html?highlight=tkfiledialog#tkinter-modules

"Other modules that provide Tk support include:
[...]
tkFileDialog
Common dialogs to allow the user to specify a file to open or save.
[...]
These have been renamed as well in Python 3; they were all made submodules of the new tkinter package."

----------
nosy: +ned.deily
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39370>
_______________________________________

From report at bugs.python.org  Fri Jan 17 14:49:57 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 17 Jan 2020 19:49:57 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1579072848.56.0.254568201766.issue37224@roundup.psfhosted.org>
Message-ID: <CALFfu7D2fFxmPKEEENpUxMkjXpWLXKJ=H+gaxu2HEZ9zz1hP8A@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Wed, Jan 15, 2020 at 12:20 AM Kyle Stanley <report at bugs.python.org> wrote:
> As can be seen from the results above, the interpreter is not even running in the first place before
> it's destroyed, so of course destroy() won't raise an RuntimeError. I think this proves that
> interpreters.destroy() is _not_ where we should be focusing our efforts (at least for now). Instead,
> we should first investigate why it's not even running at this point.

Good catch.

> I suspect the issue _might_ be a race condition within the "_running()" context manager that's
> preventing the interpreter from being ran, but I'll have to do some further investigation.

Sounds good.

> Notably, a rather difficult and hard to explain side effect occurred from adding the new assertion.
> [snip]
> But, I have no explanation for this.

Yeah, that sounds a bit strange.  Keep in mind that there have been
other changes in this part of the runtime code, so this might be
related.  Or I suppose it could be a side effect of calling
is_running() (though that definitely should not have side effects).

> do you think it might be worth adding in the changes I made to DestroyTests.test_still_running above?

Yeah, it's a good sanity check on the assumptions made by the test.
Please do open a PR and request a review from me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Fri Jan 17 14:52:11 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 17 Jan 2020 19:52:11 +0000
Subject: [issue36710] Pass _PyRuntimeState as an argument rather than using
 the _PyRuntime global variable
In-Reply-To: <1578931707.6.0.917944080894.issue36710@roundup.psfhosted.org>
Message-ID: <CALFfu7B+jBHr85q8NX5yey2hK8WMW8YxWzn8eh4ys1=EXirkHA@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks, Victor!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36710>
_______________________________________

From report at bugs.python.org  Fri Jan 17 14:59:52 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Fri, 17 Jan 2020 19:59:52 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579291192.86.0.466544894287.issue38076@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

Hey all, I've got a fix for this bug and the CI is green: https://github.com/python/cpython/pull/18039

TL;DR: The module state have to be cleared at a later time. I explain in detail in the PR.

Also, I didn't add a new test since there was a test that was already checking for module states in `io`. I added a short comment on it in the PR as well. Otherwise, lmk and I can create a new test for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Fri Jan 17 15:09:57 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Jan 2020 20:09:57 +0000
Subject: [issue32615] Inconsistent behavior if globals is a dict subclass
In-Reply-To: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>
Message-ID: <1579291797.94.0.72621783083.issue32615@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Paul, your attitude on this issue has unfortunately begun violating the PSF Code of Conduct which this issue tracker adheres to. I realize you're frustrated that the change you are after is not happening, but that doesn't mean you can deride others like you have been.

Pablo tried to ask you nicely to change your tone, but now please consider this an official warning that if your communication style does not become more civil you will most likely end up with your account suspended. I have also let the Conduct WG know about this thread and warning for record-keeping purposes.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Fri Jan 17 15:35:51 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 17 Jan 2020 20:35:51 +0000
Subject: [issue39352] Remove the formatter module, deprecated since Python 3.4
In-Reply-To: <1579164481.25.0.406270516611.issue39352@roundup.psfhosted.org>
Message-ID: <1579293351.73.0.963812656427.issue39352@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

This is already covered in https://www.python.org/dev/peps/pep-0594/ for removal in 3.10, so probably best to help get that PEP accepted first then deal with the removal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39352>
_______________________________________

From report at bugs.python.org  Fri Jan 17 15:57:16 2020
From: report at bugs.python.org (gaborbernat)
Date: Fri, 17 Jan 2020 20:57:16 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579294636.15.0.823897263106.issue17005@roundup.psfhosted.org>


gaborbernat <gaborjbernat at gmail.com> added the comment:

I think the new interface feeds better for usage in both sequential or parallel workflows, which means we can use a single UI for both, so ? from myself

----------
nosy: +gaborbernat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Fri Jan 17 16:59:35 2020
From: report at bugs.python.org (John Haley)
Date: Fri, 17 Jan 2020 21:59:35 +0000
Subject: [issue39373] new world
Message-ID: <1579298375.7.0.386428246694.issue39373@roundup.psfhosted.org>


Change by John Haley <johnjameshaley at gmail.com>:


----------
nosy: John Haley
priority: normal
severity: normal
status: open
title: new world

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39373>
_______________________________________

From report at bugs.python.org  Fri Jan 17 17:55:56 2020
From: report at bugs.python.org (Jack O'Connor)
Date: Fri, 17 Jan 2020 22:55:56 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1579301756.55.0.342940986924.issue39298@roundup.psfhosted.org>


Jack O'Connor <oconnor663 at gmail.com> added the comment:

I plan to bring the C code up to speed with the Rust code this week. As part of that, I'll probably remove comments like the one above :) Otherwise, is there anything else we can do on our end to help with this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Fri Jan 17 17:59:50 2020
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jan 2020 22:59:50 +0000
Subject: [issue39305] Merge nntplib._NNTPBase and nntplib.NNTP
In-Reply-To: <1578757948.77.0.383613154988.issue39305@roundup.psfhosted.org>
Message-ID: <1579301990.79.0.51127625095.issue39305@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17439
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18045

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39305>
_______________________________________

From report at bugs.python.org  Fri Jan 17 18:05:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 17 Jan 2020 23:05:50 +0000
Subject: [issue39343] Travis CI: documentation job fails in
 library/nntplib.rst with random network issue on news.gmane.io
In-Reply-To: <1579083774.85.0.947952738007.issue39343@roundup.psfhosted.org>
Message-ID: <1579302350.61.0.599446892588.issue39343@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It seems like the GMANE server has been fixed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39343>
_______________________________________

From report at bugs.python.org  Fri Jan 17 18:10:16 2020
From: report at bugs.python.org (Luciana)
Date: Fri, 17 Jan 2020 23:10:16 +0000
Subject: [issue39305] Merge nntplib._NNTPBase and nntplib.NNTP
In-Reply-To: <1578757948.77.0.383613154988.issue39305@roundup.psfhosted.org>
Message-ID: <1579302616.17.0.342106138862.issue39305@roundup.psfhosted.org>


Luciana <lucianadacostamarques at gmail.com> added the comment:

I just uploaded the PR, please take a look when you have a chance :)

I did my best trying to come up with a good code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39305>
_______________________________________

From report at bugs.python.org  Fri Jan 17 18:11:22 2020
From: report at bugs.python.org (=?utf-8?q?Carlos_Segura_Gonz=C3=A1lez?=)
Date: Fri, 17 Jan 2020 23:11:22 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
Message-ID: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>


New submission from Carlos Segura Gonz?lez <carlos.segura at cimat.mx>:

In the Documentation, the "Sorting HOW TO" (https://docs.python.org/3/howto/sorting.html) states that "have a key parameter to specify a function to be called". However, it might be other callable objects. In fact, some of the examples given in the documentation are not with functions.

I suggest: "have a key parameter to specify a callable object that is called..."

----------
assignee: docs at python
components: Documentation
messages: 360219
nosy: Carlos Segura Gonz?lez, docs at python
priority: normal
severity: normal
status: open
title: Key in sort -> Callable Object instead of function
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/issue39374>
_______________________________________

From report at bugs.python.org  Fri Jan 17 18:12:33 2020
From: report at bugs.python.org (=?utf-8?q?Carlos_Segura_Gonz=C3=A1lez?=)
Date: Fri, 17 Jan 2020 23:12:33 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
In-Reply-To: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>
Message-ID: <1579302753.52.0.638235845792.issue39374@roundup.psfhosted.org>


Change by Carlos Segura Gonz?lez <carlos.segura at cimat.mx>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39374>
_______________________________________

From report at bugs.python.org  Fri Jan 17 18:23:43 2020
From: report at bugs.python.org (Anthony Flury)
Date: Fri, 17 Jan 2020 23:23:43 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
In-Reply-To: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>
Message-ID: <1579303423.94.0.78551834741.issue39374@roundup.psfhosted.org>


Anthony Flury <anthony.flury at btinternet.com> added the comment:

I will submit a documentation only fix for this in the next day or so.

----------
nosy: +anthony-flury

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39374>
_______________________________________

From report at bugs.python.org  Fri Jan 17 18:45:39 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jan 2020 23:45:39 +0000
Subject: [issue39293] Windows 10 64-bit needs reboot after install
In-Reply-To: <1578690694.46.0.197073018811.issue39293@roundup.psfhosted.org>
Message-ID: <1579304739.44.0.444118526606.issue39293@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Windows 10 64-bit needs reboot -> Windows 10 64-bit needs reboot after install

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39293>
_______________________________________

From report at bugs.python.org  Fri Jan 17 19:36:08 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 18 Jan 2020 00:36:08 +0000
Subject: [issue39375] Document os.environ[x] = y and os.putenv() as thread
 unsafe
Message-ID: <1579307768.04.0.648412303004.issue39375@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

The underlying API calls made by os.putenv() and os.environ[name] = value syntax are not thread safe on POSIX systems.  POSIX _does not have_ any thread safe way to access the process global environment.

In a pure Python program, the GIL prevents this from being an issue.  But when embedded in a C/C++ program or using extension modules that launch their own threads from C, those threads could also make the invalid assumption that they can safely _read_ the environment.  Which is a race condition when a Python thread is doing a putenv() at the same time.

We should document the danger.

CPython's os module snapshots a copy of the environment into a dict at import time (during CPython startup).  But os.environ[] assignment and os.putenv() modify the actual process global environment in addition to updating this dict.  (If an embedded interpreter is launched from a process with other threads already running, even that initial environment reading could be unsafe if the larger application has a thread that wrongly assumes it has exclusive environment access)

For people modifying os.environ so that the change is visible to child processes, we can recommend using the env= parameter on subprocess API calls to supply a new environment.

A broader issue of should we be modifying the process global environment state at all from os.putenv() and os.environ[] assignment still exists.  I'll track that in another issue (to be opened).

----------
assignee: docs at python
components: Documentation
messages: 360221
nosy: docs at python, gregory.p.smith
priority: normal
severity: normal
status: open
title: Document os.environ[x] = y and os.putenv() as thread unsafe
versions: Python 2.7, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39375>
_______________________________________

From report at bugs.python.org  Fri Jan 17 19:47:44 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 18 Jan 2020 00:47:44 +0000
Subject: [issue39376] Avoid modifying the process global environment (not
 thread safe)
Message-ID: <1579308464.24.0.791579553009.issue39376@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

For more context, see https://bugs.python.org/issue39375 which seeks to document the existing caveats.

POSIX lacks any APIs to access the process global environment in a thread safe manner.  Given this, we could _consider_ preventing os.putenv() and os.environ[x] = y assignment from actually modifying the process global environment.  They'd save their changes in our local os.environ underlying dict, set a flag that it was modified, but not modify the global.

This would be a visible behavior change and break _some_ class of code. :/

Our stdlib codepaths that launch a new process on POSIX could be modified to to always pass our a newly constructed envp from os.environ to exec/spawn APIs.  The os.system() API would need to stop using the POSIX system() API call in order for that to work.

Downside API breakage: Extension module modifications to the environment would not be picked up by Python interpreter launched subprocesses.  How much of a problem would that be in practice?

We may decide to close this as infeasible and just stick with the documentation of the sorry state of POSIX and not attempt to offer any safe non-crash-possible workarounds.

----------
components: Interpreter Core
messages: 360222
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Avoid modifying the process global environment (not thread safe)
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39376>
_______________________________________

From report at bugs.python.org  Fri Jan 17 19:47:59 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 18 Jan 2020 00:47:59 +0000
Subject: [issue39375] Document os.environ[x] = y and os.putenv() as thread
 unsafe
In-Reply-To: <1579307768.04.0.648412303004.issue39375@roundup.psfhosted.org>
Message-ID: <1579308479.3.0.217489647015.issue39375@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

https://bugs.python.org/issue39376 tracks possible interpreter behavior changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39375>
_______________________________________

From report at bugs.python.org  Fri Jan 17 20:30:50 2020
From: report at bugs.python.org (paul j3)
Date: Sat, 18 Jan 2020 01:30:50 +0000
Subject: [issue36078] argparse: positional with type=int,
 default=SUPPRESS raise ValueError
In-Reply-To: <1550845114.74.0.376208054151.issue36078@roundup.psfhosted.org>
Message-ID: <1579311050.35.0.234315227091.issue36078@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

This is a complicated issue that needs a lot of thought and testing before we make any changes.

While all Actions have the 'required' attribute, the programmer can only set it for optionals.  _get_positional_kwargs() will raise an error if the programmer tries to set it for a positional.  For a positional its value is determined by the nargs value.

The distinction between positionals and optionals occurs through out argparse, so we shouldn't put much effort (if any) into making their handling more uniform.  (The fundamental distinction between the two is whether the action.option_strings list is empty or not.)

A fundamental difference in parsing is that an optional's Action is called only if the flag is used.  A positional's Action is always called.   

_parse_known_args starts with a list of positionals

    positionals = self._get_positional_actions()

The nested consume_positionals function removes actions from this list.

Earlier versions raised an error at the end of parsing if this list was not empty.  In the current version that's been replace by the 'required_actions' test (which tests both positionals and optionals).  It was this change over that resulted in the bug/feature that subparsers (a positionals Action) are no longer required (by default).

Positionals with nargs='?' and '*' pose an extra challenge.  They are, in a sense, no longer 'required'.  But they will always be 'seen' because their nargs is satisfied by an empty list of values.  But that would overwrite any 'default' in the Namespace.  So there's the added step in _get_values of (re)inserting the action.default.  And it's the handling of that 'default' that gives rise to the current issue.

These two positionals can also be used in a mutually_exclusive_group.  To handle that 'take_action' has to maintain both the 'seen_actions' set and the  'seen_non_default_actions' set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36078>
_______________________________________

From report at bugs.python.org  Fri Jan 17 20:33:02 2020
From: report at bugs.python.org (Eric Snow)
Date: Sat, 18 Jan 2020 01:33:02 +0000
Subject: [issue39376] Avoid modifying the process global environment (not
 thread safe)
In-Reply-To: <1579308464.24.0.791579553009.issue39376@roundup.psfhosted.org>
Message-ID: <1579311182.87.0.370824672824.issue39376@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

+1

This has impact on subinterpreters once they stop sharing the GIL.  (It's already on my list of global resources that need better protection.)

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39376>
_______________________________________

From report at bugs.python.org  Fri Jan 17 20:46:59 2020
From: report at bugs.python.org (paul j3)
Date: Sat, 18 Jan 2020 01:46:59 +0000
Subject: [issue39283] Add ability to inherit unittest arguement parser
In-Reply-To: <1578630738.78.0.369523186494.issue39283@roundup.psfhosted.org>
Message-ID: <1579312019.2.0.624443405211.issue39283@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

The issue of testing a script that uses argparse has come up on StackOverFlow a number of times.  

As noted the unittesting framework(s) often use their own parsers (not necessarily argparse).  That means they are looking at the sys.argv commandline.  It is difficult then to provide arguments that apply both to the framework, and your own script.  If you try to your own options, the unittest parser will complain about unrecognized arguments.

As a first step, your parser should only run when used as a script, not when imported (by the unittester).  In other words, only call `parse_args` in the 'if __name__' block.

If you do need to do unittesting of your parser, there are several monkey-patching options:

    use 'parser.parse_args(argv)' calls, where 'argv' can be None if used as script, and a custom list when being tested.  Some will modify the sys.argv during testing.  The test_argparse.py unittest file tests both ways.

    testing parser output may also require patching.  Help and errors are sent to sys.stdout or sys.stderr.  test_argparse.py uses an ArgumentParser subclass that redefines the error() and exit() methods, and redirects stdout/err.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39283>
_______________________________________

From report at bugs.python.org  Fri Jan 17 21:00:44 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Jan 2020 02:00:44 +0000
Subject: [issue39373] new world
Message-ID: <1579312844.33.0.404228365742.issue39373@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

Please include a description of the issue you are facing and how it's a CPython bug. With an empty report this would be closed.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39373>
_______________________________________

From report at bugs.python.org  Fri Jan 17 22:01:21 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 18 Jan 2020 03:01:21 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
In-Reply-To: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>
Message-ID: <1579316481.84.0.790207662117.issue39374@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I think that "HOW TO"s are fundamentally different from the "regular" documentation, in that they focus on explaining only the usual use cases and valuing simple explanations over the correct ones. Of course this _can_ be fixed, but I don't think that it must be done.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39374>
_______________________________________

From report at bugs.python.org  Fri Jan 17 22:15:05 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 18 Jan 2020 03:15:05 +0000
Subject: [issue39372] The header files in Include/ have many declarations with
 no definition
In-Reply-To: <1579283234.13.0.0884348783159.issue39372@roundup.psfhosted.org>
Message-ID: <1579317305.79.0.127553875602.issue39372@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset cd7db76a636c218b2d81d3526eb435cfae61f212 by Pablo Galindo in branch 'master':
bpo-39372: Clean header files of declared interfaces with no implementations (GH-18037)
https://github.com/python/cpython/commit/cd7db76a636c218b2d81d3526eb435cfae61f212


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39372>
_______________________________________

From report at bugs.python.org  Fri Jan 17 22:15:46 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 18 Jan 2020 03:15:46 +0000
Subject: [issue39372] The header files in Include/ have many declarations with
 no definition
In-Reply-To: <1579283234.13.0.0884348783159.issue39372@roundup.psfhosted.org>
Message-ID: <1579317346.21.0.431735843316.issue39372@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39372>
_______________________________________

From report at bugs.python.org  Fri Jan 17 22:15:58 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 18 Jan 2020 03:15:58 +0000
Subject: [issue39331] 2to3 mishandles indented imports
In-Reply-To: <1579016858.37.0.175118756285.issue39331@roundup.psfhosted.org>
Message-ID: <1579317358.09.0.334553603952.issue39331@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Thank you for the report.  This is a duplicate of #38681.

----------
nosy: +cheryl.sabella
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> 2to3 Conversion Result using BlankLine() can be Syntactically Incorrect

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39331>
_______________________________________

From report at bugs.python.org  Fri Jan 17 22:19:17 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Jan 2020 03:19:17 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
In-Reply-To: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>
Message-ID: <1579317557.5.0.583661695822.issue39374@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39374>
_______________________________________

From report at bugs.python.org  Fri Jan 17 22:21:31 2020
From: report at bugs.python.org (=?utf-8?q?Carlos_Segura_Gonz=C3=A1lez?=)
Date: Sat, 18 Jan 2020 03:21:31 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
In-Reply-To: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>
Message-ID: <1579317691.01.0.0802298469235.issue39374@roundup.psfhosted.org>


Carlos Segura Gonz?lez <carlos.segura at cimat.mx> added the comment:

The thing is that even in the "Language Reference" is not correct. In "https://docs.python.org/3/library/functions.html#sorted" it is stated "key specifies a function of one argument that is used to extract a comparison key..."

I think that it is better to use the term callable object. In the case of the HOW-TO, maybe it would be good to clarify that a function is an example of a callable object or include a reference or something like that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39374>
_______________________________________

From report at bugs.python.org  Fri Jan 17 23:31:37 2020
From: report at bugs.python.org (paul j3)
Date: Sat, 18 Jan 2020 04:31:37 +0000
Subject: [issue39197] argparse: title and description for mutually exclusive
 arg groups
In-Reply-To: <1577995665.78.0.21290537011.issue39197@roundup.psfhosted.org>
Message-ID: <1579321897.13.0.871645537643.issue39197@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

A mutually_exclusive_group is not an argument_group.  It affects parsing and the usage, but does nothing in the help lines.

A mutually_exclusive_group may be nested in an argument_group if you want another group title.  

     g1 = parser.add_argument_group('My Required Group')
     g2 = g1.add_mutually_exclusive_group(....)

Groups are not really designed for nesting, but this is one case the nesting works and is useful.  Nesting, to the extent it works, is simple a consequence of inheritance from the _Argument_Container class.

Changing the title of the default action group is always an option, mutually_exclusive or not.  Other bug/issues have suggest changing that title at creation time, or giving the user a choice (maybe even defining 3 default groups).  But for now we recommend creating your own argument group(s) if you don't like the titles of the default one(s).

So no, I don't think anything should be changed simply because a mutually_exclusive group is marked as required.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39197>
_______________________________________

From report at bugs.python.org  Fri Jan 17 23:56:23 2020
From: report at bugs.python.org (paul j3)
Date: Sat, 18 Jan 2020 04:56:23 +0000
Subject: [issue39173] _AttributeHolder of argparse should support the sort
 function or not?
In-Reply-To: <1577805833.81.0.166775558073.issue39173@roundup.psfhosted.org>
Message-ID: <1579323383.57.0.87674061072.issue39173@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

I don't think the SO question is relevant.  It's about changing the order of Actions in the Help and/or usage.    

Here it's a question of whether to sort the  `argparse.Namespace` display.  I think it's been adequately discussed in the recent bug/issues such as 39058.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39173>
_______________________________________

From report at bugs.python.org  Sat Jan 18 00:00:31 2020
From: report at bugs.python.org (paul j3)
Date: Sat, 18 Jan 2020 05:00:31 +0000
Subject: [issue39197] argparse: title and description for mutually exclusive
 arg groups
In-Reply-To: <1577995665.78.0.21290537011.issue39197@roundup.psfhosted.org>
Message-ID: <1579323631.18.0.0607092386074.issue39197@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

https://bugs.python.org/issue9694

is the original issue about the titles of the base argument groups.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39197>
_______________________________________

From report at bugs.python.org  Sat Jan 18 00:27:40 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Jan 2020 05:27:40 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
Message-ID: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

This is a followup of issue33461. The warning says about removal of the encoding parameter in 3.9 . It's already ignored since 3.1 hence I assume this should be raising a TypeError in 3.9 removing the deprecation warning. I am finding some projects using the encoding parameter though it has no effect. Since Python 3.9 has alpha 3 to be released it will be good to fix the deprecation in the early stage of release cycle.

----------
components: Library (Lib)
messages: 360235
nosy: inada.naoki, serhiy.storchaka, vstinner, xtreak
priority: normal
severity: normal
status: open
title: json.loads encoding parameter deprecation removal in Python 3.9
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Sat Jan 18 00:31:27 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 18 Jan 2020 05:31:27 +0000
Subject: [issue39378] partial of PickleState struct should be traversed.
Message-ID: <1579325487.94.0.252462243653.issue39378@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

As subject, looks partial of PickleState struct should be traversed.

----------
components: Extension Modules
messages: 360236
nosy: shihai1991
priority: normal
severity: normal
status: open
title: partial of PickleState struct should be traversed.
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39378>
_______________________________________

From report at bugs.python.org  Sat Jan 18 00:40:34 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 18 Jan 2020 05:40:34 +0000
Subject: [issue39378] partial of PickleState struct should be traversed.
In-Reply-To: <1579325487.94.0.252462243653.issue39378@roundup.psfhosted.org>
Message-ID: <1579326034.93.0.647729519067.issue39378@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +17441
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18046

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39378>
_______________________________________

From report at bugs.python.org  Sat Jan 18 00:49:51 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 18 Jan 2020 05:49:51 +0000
Subject: [issue39173] _AttributeHolder of argparse should support the sort
 function or not?
In-Reply-To: <1577805833.81.0.166775558073.issue39173@roundup.psfhosted.org>
Message-ID: <1579326591.12.0.887852526205.issue39173@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

paul said in issue 39058: `Anyways removing the sort makes sense, and the proposed change phrase "in the order attributes were added" is sufficiently general.`

I agree paul's opinion now. The functionality meets users' needs now, so we don't need spend much time in it;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39173>
_______________________________________

From report at bugs.python.org  Sat Jan 18 01:52:47 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 18 Jan 2020 06:52:47 +0000
Subject: [issue38848] compileall fails when the platform lacks a functional
 sem_open()
In-Reply-To: <1574178213.95.0.878583354455.issue38848@roundup.psfhosted.org>
Message-ID: <1579330367.86.0.444878863531.issue38848@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +17442
pull_request: https://github.com/python/cpython/pull/18047

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38848>
_______________________________________

From report at bugs.python.org  Sat Jan 18 01:56:03 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 18 Jan 2020 06:56:03 +0000
Subject: [issue38848] compileall fails when the platform lacks a functional
 sem_open()
In-Reply-To: <1574178213.95.0.878583354455.issue38848@roundup.psfhosted.org>
Message-ID: <1579330563.86.0.111481533448.issue38848@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38848>
_______________________________________

From report at bugs.python.org  Sat Jan 18 01:57:02 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 18 Jan 2020 06:57:02 +0000
Subject: [issue39372] The header files in Include/ have many declarations with
 no definition
In-Reply-To: <1579283234.13.0.0884348783159.issue39372@roundup.psfhosted.org>
Message-ID: <1579330622.18.0.832835039411.issue39372@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

The removal of PyNoArgsFunction is the subject of bpo-18091.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39372>
_______________________________________

From report at bugs.python.org  Sat Jan 18 02:46:57 2020
From: report at bugs.python.org (Ken Sato)
Date: Sat, 18 Jan 2020 07:46:57 +0000
Subject: [issue39379] sys.path[0] is already absolute path
Message-ID: <1579333617.11.0.372896670301.issue39379@roundup.psfhosted.org>


New submission from Ken Sato <ksato9700 at gmail.com>:

In the "What?s New In Python 3.9" (Doc/whatsnew/3.9.rst), it says

> Python now gets the absolute path of the script filename specified on the command line (ex: python3 script.py): the __file__ attribute of the __main__ module and sys.path[0] become an absolute path, rather than a relative path.

However, I believe sys.path[0] is already absolute path since the previous versions. We can probably remove "and sys.path[0]" from the phrase to avoid possible confusions.

----------
assignee: docs at python
components: Documentation
messages: 360239
nosy: docs at python, ksato9700
priority: normal
severity: normal
status: open
title: sys.path[0] is already absolute path
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39379>
_______________________________________

From report at bugs.python.org  Sat Jan 18 03:42:56 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Jan 2020 08:42:56 +0000
Subject: [issue39379] sys.path[0] is already absolute path
In-Reply-To: <1579333617.11.0.372896670301.issue39379@roundup.psfhosted.org>
Message-ID: <1579336976.78.0.0476648871097.issue39379@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39379>
_______________________________________

From report at bugs.python.org  Sat Jan 18 04:06:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jan 2020 09:06:06 +0000
Subject: [issue39372] The header files in Include/ have many declarations with
 no definition
In-Reply-To: <1579283234.13.0.0884348783159.issue39372@roundup.psfhosted.org>
Message-ID: <1579338366.04.0.272828256865.issue39372@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Maybe backport this change (except PyNoArgsFunction)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39372>
_______________________________________

From report at bugs.python.org  Sat Jan 18 04:27:00 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jan 2020 09:27:00 +0000
Subject: [issue18091] Remove PyNoArgsFunction
In-Reply-To: <1369792844.19.0.815911667989.issue18091@psf.upfronthosting.co.za>
Message-ID: <1579339620.66.0.902969120145.issue18091@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Removed in issue39372 together with other unused declarations.

PyNoArgsFunction was the only one that breaks a user code. But using PyNoArgsFunction is likely a sign of error.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> The header files in Include/ have many declarations with no definition

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18091>
_______________________________________

From report at bugs.python.org  Sat Jan 18 04:29:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 18 Jan 2020 09:29:35 +0000
Subject: [issue18091] Remove PyNoArgsFunction
In-Reply-To: <1369792844.19.0.815911667989.issue18091@psf.upfronthosting.co.za>
Message-ID: <1579339775.04.0.0269167487792.issue18091@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I cannot report a bug in Blender, because get an exception on link https://developer.blender.org/maniphest/project/2/type/Bug/ .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18091>
_______________________________________

From report at bugs.python.org  Sat Jan 18 04:57:38 2020
From: report at bugs.python.org (Sebastian G Pedersen)
Date: Sat, 18 Jan 2020 09:57:38 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
Message-ID: <1579341458.55.0.271160828625.issue39380@roundup.psfhosted.org>


Change by Sebastian G Pedersen <sebastian.g.pedersen at gmail.com>:


----------
components: Library (Lib)
nosy: SebastianGPedersen
priority: normal
severity: normal
status: open
title: ftplib uses latin-1 as default encoding
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/issue39380>
_______________________________________

From report at bugs.python.org  Sat Jan 18 05:06:03 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 18 Jan 2020 10:06:03 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
Message-ID: <1579341963.28.0.683843956923.issue39380@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Sat Jan 18 05:27:29 2020
From: report at bugs.python.org (Sebastian G Pedersen)
Date: Sat, 18 Jan 2020 10:27:29 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
Message-ID: <1579343249.51.0.268494908787.issue39380@roundup.psfhosted.org>


Change by Sebastian G Pedersen <sebastian.g.pedersen at gmail.com>:


----------
keywords: +patch
pull_requests: +17443
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18048

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Sat Jan 18 05:45:16 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 18 Jan 2020 10:45:16 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1579344316.98.0.266477365765.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17444
pull_request: https://github.com/python/cpython/pull/18049

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sat Jan 18 06:05:22 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 18 Jan 2020 11:05:22 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1579345522.94.0.738834501096.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17445
pull_request: https://github.com/python/cpython/pull/18050

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sat Jan 18 07:49:29 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Jan 2020 12:49:29 +0000
Subject: [issue39309] Please delete my account
Message-ID: <1579351769.04.0.498329028577.issue39309@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

David, do you know about bpo account deletion?

----------
nosy: +r.david.murray, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39309>
_______________________________________

From report at bugs.python.org  Sat Jan 18 07:51:05 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Jan 2020 12:51:05 +0000
Subject: [issue39316] settrace skips lines when chaining methods without
 arguments
In-Reply-To: <1578863624.84.0.650995733403.issue39316@roundup.psfhosted.org>
Message-ID: <1579351865.26.0.561139013167.issue39316@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39316>
_______________________________________

From report at bugs.python.org  Sat Jan 18 08:07:51 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 18 Jan 2020 13:07:51 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
Message-ID: <1579352871.2.0.111986726636.issue39380@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Sat Jan 18 08:30:41 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 18 Jan 2020 13:30:41 +0000
Subject: [issue39381] Fix get_event_loop documentation
Message-ID: <1579354241.45.0.104349162739.issue39381@roundup.psfhosted.org>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

The current documentation says: "If there is no current event loop set in the current OS thread and set_event_loop() has not yet been called, asyncio will create a new event loop and set it as the current one."

https://docs.python.org/3.7/library/asyncio-eventloop.html#asyncio.get_event_loop

This is not correct, a new loop is created implicitly only for the main thread, all other threads require set_event_loop() call

----------
components: asyncio
messages: 360244
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Fix get_event_loop documentation
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39381>
_______________________________________

From report at bugs.python.org  Sat Jan 18 08:39:59 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 18 Jan 2020 13:39:59 +0000
Subject: [issue39381] Fix get_event_loop documentation
In-Reply-To: <1579354241.45.0.104349162739.issue39381@roundup.psfhosted.org>
Message-ID: <1579354799.62.0.0768805048637.issue39381@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +17446
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18051

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39381>
_______________________________________

From report at bugs.python.org  Sat Jan 18 08:51:36 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 18 Jan 2020 13:51:36 +0000
Subject: [issue30744] Local variable assignment is broken when combined with
 threads + tracing + closures
In-Reply-To: <1498277129.07.0.940069687434.issue30744@psf.upfronthosting.co.za>
Message-ID: <1579355496.51.0.126745857903.issue30744@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests: +17447
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18052

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30744>
_______________________________________

From report at bugs.python.org  Sat Jan 18 09:07:02 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 18 Jan 2020 14:07:02 +0000
Subject: [issue39375] Document os.environ[x] = y and os.putenv() as thread
 unsafe
In-Reply-To: <1579307768.04.0.648412303004.issue39375@roundup.psfhosted.org>
Message-ID: <1579356422.98.0.720330231724.issue39375@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The warning would not apply to Windows. The environment block is part of the Process Environment Block (PEB) record, which is protected by a critical-section lock. The runtime library acquires the PEB lock before accessing mutable PEB values. For example:

Getting an environment variable:

    >>> win32api.GetEnvironmentVariable('foo')

        Breakpoint 0 hit
        ntdll!RtlQueryEnvironmentVariable:
        00007ffc`d737a2f0 48895c2408      mov     qword ptr [rsp+8],rbx
            ss:00000094`ec9ef470=0000000000000000

RtlQueryEnvironmentVariable acquires the PEB lock (i.e. ntdll!FastPebLock) before getting the value. The lock is passed to RtlEnterCriticalSection in register rcx:

        0:000> be 2; g

        Breakpoint 2 hit
        ntdll!RtlEnterCriticalSection:
        00007ffc`d737b400 4883ec28        sub     rsp,28h

        0:000> kc 3
        Call Site
        ntdll!RtlEnterCriticalSection
        ntdll!RtlQueryEnvironmentVariable
        KERNELBASE!GetEnvironmentVariableW

        0:000> ?? @rcx == (_RTL_CRITICAL_SECTION *)@@(ntdll!FastPebLock)
        bool true

Setting an environment variable:

    >>> win32api.SetEnvironmentVariable('foo', 'eggs')

        Breakpoint 1 hit
        ntdll!RtlSetEnvironmentVar:
        00007ffc`d73bc7d0 4c894c2420      mov     qword ptr [rsp+20h],r9 ss:00000094`ec9ef488=0000000000000000

RtlSetEnvironmentVar acquires the PEB lock before setting the environment variable:

        0:000> be 2; g

        Breakpoint 2 hit
        ntdll!RtlEnterCriticalSection:
        00007ffc`d737b400 4883ec28        sub     rsp,28h

        0:000> kc 3
        Call Site
        ntdll!RtlEnterCriticalSection
        ntdll!RtlSetEnvironmentVar
        KERNELBASE!SetEnvironmentVariableW

        0:000> ?? @rcx == (_RTL_CRITICAL_SECTION *)@@(ntdll!FastPebLock)
        bool true

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39375>
_______________________________________

From report at bugs.python.org  Sat Jan 18 09:36:32 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 18 Jan 2020 14:36:32 +0000
Subject: [issue39372] The header files in Include/ have many declarations with
 no definition
In-Reply-To: <1579283234.13.0.0884348783159.issue39372@roundup.psfhosted.org>
Message-ID: <1579358192.65.0.179632651778.issue39372@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Maybe backport this change (except PyNoArgsFunction)?

I didn't think of backporting to reduce the possibilities of something going wrong, but is true that a backport without PyNoArgsFunction should be harmless.

Reopening the issue meanwhile I do on the backports.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39372>
_______________________________________

From report at bugs.python.org  Sat Jan 18 12:30:12 2020
From: report at bugs.python.org (Yonatan Goldschmidt)
Date: Sat, 18 Jan 2020 17:30:12 +0000
Subject: [issue39382] abstract_issubclass() doesn't take bases tuple item ref
Message-ID: <1579368612.83.0.483106486083.issue39382@roundup.psfhosted.org>


New submission from Yonatan Goldschmidt <yon.goldschmidt at gmail.com>:

I encountered a crash using rpyc. Since rpyc is pure-Python, I guessed the problem is with Python itself.

Originally tested on v3.7, the rest of this issue is based on v3.9.0a2 (compiling on an Ubuntu 18.04 docker).

I narrowed down the rpyc-based snippet to this:

    # server side
    class X: pass
    x_instance = X()

    from rpyc.core import SlaveService
    from rpyc.utils.classic import DEFAULT_SERVER_PORT
    from rpyc.utils.server import ThreadedServer
    t = ThreadedServer(SlaveService, port=DEFAULT_SERVER_PORT, reuse_addr=True)
    t.start()

    # client side
    import rpyc
    conn = rpyc.classic.connect("localhost")
    x = conn.modules.__main__.x_instance
    y = x.__class__
    issubclass(y, int)

Client side gets a SIGSEGV in `_PyObject_LookupAttr`, dereferencing an invalid `tp` pointer read from a posioned `v` object.

After some reference count debugging, I found that for the rpyc `y` object (in the client code), accessing `__bases__` returns a tuple with refcount=1, and it has a single item whose refcount is 1 as well.

abstract_issubclass() calls abstract_get_bases() to get this refcount=1 tuple, and in the fastpath for single inheritance (tuple size = 1) it loads the single item from the tuple (`derived = PyTuple_GET_ITEM(bases, 0)`) and then decrements the refcount on the tuple, effectively deallocating the tuple and the `derived` object (whose only reference was from the tuple).

I tried to mimic the Python magic rpyc does to get the same crash without rpyc, and reached the following snippet (which doesn't exhibit the problem):

    class Meta(type):
        def __getattribute__(self, attr):
            if attr == "__bases__":
                class Base: pass
                return (Base, )
            return type.__getattribute__(self, attr)

    class X(metaclass=Meta):
        pass

    issubclass(X().__class__, int)

In this case, the refcount is decremented from 4 to 3 as abstract_issubclass() gets rid of the tuple (instead of from 1 to 0 as happens in the rpyc case). I don't know how rpyc does it.

Attached is a patch that solves the problem (takes a ref of the tuple item before releasing the ref of the tuple itself).
I'm not sure this change is worth the cost because, well, I don't fully understand the severity of it since I couldn't reproduce it without using rpyc. I assume dynamically-created, unreferenced `__bases__` tuples as I have here are not so common.

Anyway, if you do decide it's worth it, I'd be happy to improve the patch (it's quite messy the way this function is structured) and post it to GitHub :)

Yonatan

----------
components: Interpreter Core
files: abstract_issubclass_refcount_fix.diff
keywords: patch
messages: 360247
nosy: Yonatan Goldschmidt
priority: normal
severity: normal
status: open
title: abstract_issubclass() doesn't take bases tuple item ref
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file48851/abstract_issubclass_refcount_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39382>
_______________________________________

From report at bugs.python.org  Sat Jan 18 12:57:43 2020
From: report at bugs.python.org (Peter Bittner)
Date: Sat, 18 Jan 2020 17:57:43 +0000
Subject: [issue39383] Mention Darwin as a potential value for platform.system()
Message-ID: <1579370263.63.0.178339292533.issue39383@roundup.psfhosted.org>


New submission from Peter Bittner <peter.bittner at gmx.net>:

The platform module's documentation mentions 'Linux', 'Windows' and 'Java' explicitly as values for `platform.system()`.

https://docs.python.org/3/library/platform.html#platform.system

Given the popularity of macOS among developers, this gives the impression that the module won't detect 'Darwin' as a separate system type; developers may suspect this will be identified also as a "Linux-y" system (or so).

Hence, 'Darwin' should be mentioned explicitly as one of the possible values.

----------
assignee: docs at python
components: Documentation
messages: 360248
nosy: bittner, docs at python
priority: normal
pull_requests: 17448
severity: normal
status: open
title: Mention Darwin as a potential value for platform.system()
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39383>
_______________________________________

From report at bugs.python.org  Sat Jan 18 14:48:43 2020
From: report at bugs.python.org (Mark Sapiro)
Date: Sat, 18 Jan 2020 19:48:43 +0000
Subject: [issue39384] Email parser creates a message object that can't be
 flattened as bytes.
Message-ID: <1579376923.42.0.439623129413.issue39384@roundup.psfhosted.org>


New submission from Mark Sapiro <mark at msapiro.net>:

This is similar to https://bugs.python.org/issue32330 but is the opposite behavior. In that issue, the message couldn't be flattened as a string but could be flattened as bytes. Here, the message can be flattened as a string but can't be flattened as bytes.

The original message was created by an arguably defective email client that quoted a message containing a utf8 encoded RIGHT SINGLE QUOTATION MARK and utf-8 encoded separately the three bytes resulting in `?**` instead of `?`. That's not really relevant but is just to show how such a message can be generated.

The following interactive python session shows the issue.

```
>>> import email
>>> msg = email.message_from_string("""From user at example.com Sat Jan 18 04:09:40 2020
... From: user at example.com
... To: recip at example.com
... Subject: Century Dates for Insurance purposes
... Date: Fri, 17 Jan 2020 20:09:26 -0800
... Message-ID: <75ccdd72-d71c-407c-96bd-0ca95abcfa03 at email.android.com>
... MIME-Version: 1.0
... Content-Type: text/plain; charset="utf-8"
... Content-Transfer-Encoding: 8bit
... 
...        Thursday-Monday will cover both days of staging and then storing goods
...        post-century. I think that?**s the way to go.
... 
... """)
>>> msg.as_bytes()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/email/message.py", line 178, in as_bytes
    g.flatten(self, unixfrom=unixfrom)
  File "/usr/local/lib/python3.7/email/generator.py", line 116, in flatten
    self._write(msg)
  File "/usr/local/lib/python3.7/email/generator.py", line 181, in _write
    self._dispatch(msg)
  File "/usr/local/lib/python3.7/email/generator.py", line 214, in _dispatch
    meth(msg)
  File "/usr/local/lib/python3.7/email/generator.py", line 432, in _handle_text
    super(BytesGenerator,self)._handle_text(msg)
  File "/usr/local/lib/python3.7/email/generator.py", line 249, in _handle_text
    self._write_lines(payload)
  File "/usr/local/lib/python3.7/email/generator.py", line 155, in _write_lines
    self.write(line)
  File "/usr/local/lib/python3.7/email/generator.py", line 406, in write
    self._fp.write(s.encode('ascii', 'surrogateescape'))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe2' in position 33: ordinal not in range(128)
>>> 
```

----------
components: email
messages: 360249
nosy: barry, msapiro, r.david.murray
priority: normal
severity: normal
status: open
title: Email parser creates a message object that can't be flattened as bytes.
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39384>
_______________________________________

From report at bugs.python.org  Sat Jan 18 15:25:23 2020
From: report at bugs.python.org (Kit Yan Choi)
Date: Sat, 18 Jan 2020 20:25:23 +0000
Subject: [issue39385] Add an assertNoLogs context manager to unittest TestCase
Message-ID: <1579379123.37.0.908861475494.issue39385@roundup.psfhosted.org>


New submission from Kit Yan Choi <kit at kychoi.org>:

assertLogs is really useful (issue18937). Unfortunately it does not cover the use cases where one wants to ensure no logs are emitted.

Similar to assertLogs, we can have a context manager for asserting no logs, something like this?:

with assertNoLogs(logger, level):
    ...


If logs are unexpected found, the test would fail with the logs captured included in the error message.

Happy to submit a PR if there is interest.

----------
components: Library (Lib)
messages: 360250
nosy: Kit Yan Choi
priority: normal
severity: normal
status: open
title: Add an assertNoLogs context manager to unittest TestCase
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39385>
_______________________________________

From report at bugs.python.org  Sat Jan 18 16:36:58 2020
From: report at bugs.python.org (Jacopo Tediosi)
Date: Sat, 18 Jan 2020 21:36:58 +0000
Subject: [issue38799] race condition in multiprocessing.Pool with
 maxtasksperchild=1
In-Reply-To: <1573741463.54.0.726386081745.issue38799@roundup.psfhosted.org>
Message-ID: <1579383418.21.0.383450285541.issue38799@roundup.psfhosted.org>


Jacopo Tediosi <jacopotediosi at gmail.com> added the comment:

Happening to me on Python3.9 too
Also when calling pool.terminate(), causing my script to hang

----------
nosy: +Jacopo Tediosi
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38799>
_______________________________________

From report at bugs.python.org  Sat Jan 18 17:14:51 2020
From: report at bugs.python.org (Clement Rouault)
Date: Sat, 18 Jan 2020 22:14:51 +0000
Subject: [issue29270] super call in ctypes sub-class fails in 3.6
In-Reply-To: <1484345422.14.0.967631121608.issue29270@psf.upfronthosting.co.za>
Message-ID: <1579385691.22.0.176717486255.issue29270@roundup.psfhosted.org>


Clement Rouault <python at hakril.net> added the comment:

Hello,

As this issue may never be fixed for python3.6. I wanted to post a solution to bypass the bug. It may be useful for the next person stumbling on this as I have.

The __class__ closure is only created if a function use the word super(). This closure allow to call super() without argument.

By using another name than super() the closure is not created and your code can work. Only downside is that you need to call super in its explicit form super(Cls, self). But it is better that not working at all (and it is compatible python2).

Here is a sample:


super_bypass_issue29270 = super

class Something(ctypes.c_ulong):
  def __repr__(self):
    return "BYPASS: " + super_bypass_issue29270(Something, self).__repr__()

s = Something(42)
print(s)

BYPASS: <Something object at 0x00000134C9BA6848>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29270>
_______________________________________

From report at bugs.python.org  Sat Jan 18 19:52:59 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Jan 2020 00:52:59 +0000
Subject: [issue39384] Email parser creates a message object that can't be
 flattened as bytes.
In-Reply-To: <1579376923.42.0.439623129413.issue39384@roundup.psfhosted.org>
Message-ID: <1579395179.86.0.707173811709.issue39384@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17449
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18056

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39384>
_______________________________________

From report at bugs.python.org  Sat Jan 18 22:14:05 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 19 Jan 2020 03:14:05 +0000
Subject: [issue39349] Add "cancel_futures" parameter to
 concurrent.futures.Executor.shutdown()
In-Reply-To: <1579147714.25.0.252393666546.issue39349@roundup.psfhosted.org>
Message-ID: <1579403645.97.0.246406944951.issue39349@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

I now have a working implementation, for both ThreadPoolExecutor and ProcessPoolExecutor. I've also ensured that the tests I added are not vulnerable to race conditions with the following:

```
[aeros:~/repos/aeros-cpython]$ ./python -m test test_concurrent_futures --match test_cancel_futures -j200 -v -F

[snip]
Ran 4 tests in 2.865s

OK
0:03:24 load avg: 143.25 [1018] test_concurrent_futures passed -- running: test_concurrent_futures (2 min 36 sec), test_concurrent_futures (35.8 sec)
test_cancel_futures (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.57s ok
test_cancel_futures (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 0.80s ok
test_cancel_futures (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 0.53s ok
test_cancel_futures (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.20s ok
```

I'll attach a PR to the issue once I finish writing the documentation and "What's New" entry.

Note: I was originally going to do this in two separate PRs, one for each executor, but it seemed to make more sense to just have it as a single cohesive PR since Executor.shutdown() shares the same documentation for both executors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39349>
_______________________________________

From report at bugs.python.org  Sat Jan 18 23:10:56 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 19 Jan 2020 04:10:56 +0000
Subject: [issue39349] Add "cancel_futures" parameter to
 concurrent.futures.Executor.shutdown()
In-Reply-To: <1579147714.25.0.252393666546.issue39349@roundup.psfhosted.org>
Message-ID: <1579407056.62.0.982350946599.issue39349@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
keywords: +patch
pull_requests: +17451
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18057

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39349>
_______________________________________

From report at bugs.python.org  Sat Jan 18 23:43:00 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 19 Jan 2020 04:43:00 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1579408980.92.0.138740165903.issue37224@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
pull_requests: +17452
pull_request: https://github.com/python/cpython/pull/18058

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Sun Jan 19 01:05:48 2020
From: report at bugs.python.org (Mark Sapiro)
Date: Sun, 19 Jan 2020 06:05:48 +0000
Subject: [issue39384] Email parser creates a message object that can't be
 flattened as bytes.
In-Reply-To: <1579376923.42.0.439623129413.issue39384@roundup.psfhosted.org>
Message-ID: <1579413948.28.0.890134362141.issue39384@roundup.psfhosted.org>


Change by Mark Sapiro <mark at msapiro.net>:


----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39384>
_______________________________________

From report at bugs.python.org  Sun Jan 19 01:34:55 2020
From: report at bugs.python.org (Mark Sapiro)
Date: Sun, 19 Jan 2020 06:34:55 +0000
Subject: [issue32330] Email parser creates a message object that can't be
 flattened
In-Reply-To: <1513297527.86.0.213398074469.issue32330@psf.upfronthosting.co.za>
Message-ID: <1579415695.44.0.850961039372.issue32330@roundup.psfhosted.org>


Change by Mark Sapiro <mark at msapiro.net>:


----------
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32330>
_______________________________________

From report at bugs.python.org  Sun Jan 19 01:38:24 2020
From: report at bugs.python.org (Mark Sapiro)
Date: Sun, 19 Jan 2020 06:38:24 +0000
Subject: [issue32330] Email parser creates a message object that can't be
 flattened
In-Reply-To: <1513297527.86.0.213398074469.issue32330@psf.upfronthosting.co.za>
Message-ID: <1579415904.92.0.425106454202.issue32330@roundup.psfhosted.org>


Change by Mark Sapiro <mark at msapiro.net>:


----------
keywords: +patch
pull_requests: +17453
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18059

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32330>
_______________________________________

From report at bugs.python.org  Sun Jan 19 01:43:40 2020
From: report at bugs.python.org (John-Mark Gurney)
Date: Sun, 19 Jan 2020 06:43:40 +0000
Subject: [issue39386] getting invalid data from async iterator
Message-ID: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>


New submission from John-Mark Gurney <jmg at funkthat.com>:

If I create a coro from an async iterator, then wait_for it w/ a timeout, but shielded, so it won't get canceled, and then await upon it, it returns invalid data.

See the attached test case.

The reason I do the following is to make sure that an async iterator that I have written doesn't return data early, and needs to wait till later.  If I didn't shield it, then the async iterator would get cancelled, and I don't want this.

I'd expect either correct results to be returned, or an exception to be raised, but in this case, and the docs for wait_for ( https://docs.python.org/3/library/asyncio-task.html#asyncio.wait_for ), I'd expect the correct results to be returned.


In the attached case, this is the results that I get:
$python3.7 asyncitertc.py 
3.7.5 (default, Oct 18 2019, 23:59:39) 
[Clang 7.0.2 (clang-700.1.81)]
timed out
yielding 1
results: None
getting 2: 2

I do not have python 3.8 to test with.

----------
files: asyncitertc.py
messages: 360254
nosy: jmg
priority: normal
severity: normal
status: open
title: getting invalid data from async iterator
Added file: https://bugs.python.org/file48852/asyncitertc.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Sun Jan 19 01:54:51 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 19 Jan 2020 06:54:51 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1579416891.16.0.97420081611.issue35561@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +17454
pull_request: https://github.com/python/cpython/pull/18060

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35561>
_______________________________________

From report at bugs.python.org  Sun Jan 19 01:56:33 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 19 Jan 2020 06:56:33 +0000
Subject: [issue19770] NNTP: add post_message wrapper to post Email Message
 objects
In-Reply-To: <1385382524.39.0.481766399265.issue19770@psf.upfronthosting.co.za>
Message-ID: <1579416993.76.0.266780597149.issue19770@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17455
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18061

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19770>
_______________________________________

From report at bugs.python.org  Sun Jan 19 02:18:19 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Jan 2020 07:18:19 +0000
Subject: [issue39386] getting invalid data from async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1579418299.93.0.706897037433.issue39386@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +asyncio
nosy: +asvetlov, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Sun Jan 19 02:54:31 2020
From: report at bugs.python.org (Alexander Hirner)
Date: Sun, 19 Jan 2020 07:54:31 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1579420471.4.0.143493984833.issue39134@roundup.psfhosted.org>


Alexander Hirner <a.hirner at gmail.com> added the comment:

In that case, what should the getter return? It doesn't know about the implementation of x.
Maybe I'm not getting the idea behind adding getters/setters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39134>
_______________________________________

From report at bugs.python.org  Sun Jan 19 06:02:16 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 19 Jan 2020 11:02:16 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1579431736.95.0.338506202478.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17456
pull_request: https://github.com/python/cpython/pull/18065

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sun Jan 19 06:19:13 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 19 Jan 2020 11:19:13 +0000
Subject: [issue39385] Add an assertNoLogs context manager to unittest TestCase
In-Reply-To: <1579379123.37.0.908861475494.issue39385@roundup.psfhosted.org>
Message-ID: <1579432753.78.0.334042974546.issue39385@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +ezio.melotti, michael.foord, rbcollins
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39385>
_______________________________________

From report at bugs.python.org  Sun Jan 19 06:25:02 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 19 Jan 2020 11:25:02 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1579433102.75.0.584611497706.issue1635741@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17457
pull_request: https://github.com/python/cpython/pull/18066

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sun Jan 19 07:27:50 2020
From: report at bugs.python.org (sanket)
Date: Sun, 19 Jan 2020 12:27:50 +0000
Subject: [issue39365] Support (SEEK_END/SEEK_CUR) relative seeking in StringIO
In-Reply-To: <1579234995.29.0.127298904142.issue39365@roundup.psfhosted.org>
Message-ID: <1579436870.21.0.623525363461.issue39365@roundup.psfhosted.org>


sanket <sanketplus at gmail.com> added the comment:

can you provide more details? Python version and code/steps to reproduce. That'd be more helpful as it seems the methods are already implemented in latest version https://docs.python.org/3/library/io.html#io.TextIOBase.seek

----------
nosy: +sanketplus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39365>
_______________________________________

From report at bugs.python.org  Sun Jan 19 07:59:22 2020
From: report at bugs.python.org (Mattia Verga)
Date: Sun, 19 Jan 2020 12:59:22 +0000
Subject: [issue39387] configparser read_file() with variable
Message-ID: <1579438762.29.0.201953236535.issue39387@roundup.psfhosted.org>


New submission from Mattia Verga <mattia.verga at gmail.com>:

I'm trying to assign a file object to a variable and then pass this variable to configparse.read_file(), but for some reason that doesn't work:

>>> import configparser
>>> config = configparser.ConfigParser()
>>> config.read_file(open('review-stats.cfg'))
>>> config.sections()
['global']
>>>
>>> config2 = configparser.ConfigParser()
>>> f = open('review-stats.cfg')
>>> f
<_io.TextIOWrapper name='review-stats.cfg' mode='r' encoding='UTF-8'>
>>> config2.read_file(f)
>>> config2.sections()
[]

Shouldn't those results be the same?

----------
components: Library (Lib)
messages: 360257
nosy: Mattia Verga
priority: normal
severity: normal
status: open
title: configparser read_file() with variable
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39387>
_______________________________________

From report at bugs.python.org  Sun Jan 19 09:03:42 2020
From: report at bugs.python.org (Zahari Dim)
Date: Sun, 19 Jan 2020 14:03:42 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579442622.85.0.663478036515.issue17005@roundup.psfhosted.org>


Zahari Dim <zaharid at gmail.com> added the comment:

I would like to suggest a `dependency_resolver` API that I have been using that goes in line with what Tim Peters proposes in https://bugs.python.org/issue17005#msg359702

A DAG would be an object that can be iterated in topological order with __iter__ (for simple sequential usage) or have a way of managing all the tasks that can be run in parallel. The later is done with a generator function:

```
    def dependency_resolver(self):
        """Yield the set of nodes that have all dependencies satisfied (which could be an empty set). Send the next
        completed task."""
```

which is used with something like:

```
deps = dag.dependency_resolver()
pending_tasks = deps.send(None)
if not pending_tasks:
    #Graph empty
    return
#Note this is a can be done in parallel/async
while True:
    some_task = pending_tasks.pop()
    complete_task_somehow(some_task)
    try:
       more_tasks = deps.send(some_task)
    except StopIteration:
       #Exit when we have sent in all the nodes in the graph
       break
    else:
        pending_tasks |= more_tasks

```


An implementation I have used for some time is here:


https://github.com/NNPDF/reportengine/blob/master/src/reportengine/dag.py

although I'd make simpler now. In practice I have found that the function I use most of the time to build the graph is:

dag.add_or_update_node(node=something_hashable, inputs={set of existing nodes}, outputs={set of existing nodes}).

which adds the node to the graph if it was not there and maps updates the dependencies to add inputs and outputs, which in my experience matches the way one discovers dependencies for things like packages.

----------
nosy: +Zahari.Dim

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Sun Jan 19 10:23:20 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Jan 2020 15:23:20 +0000
Subject: [issue39387] configparser read_file() with variable
In-Reply-To: <1579438762.29.0.201953236535.issue39387@roundup.psfhosted.org>
Message-ID: <1579447400.8.0.796112686762.issue39387@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I can't reproduce this on Linux machine with Python 3.7 and 3.8. Assigning the open file object shouldn't really make a difference unless you are passing the same file object that was read to initialize a different configparser object.

cat review-stats.cfg
[global]
a = b

python3.7
Python 3.7.0 (default, Jun 28 2018, 00:00:00) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import configparser
>>> config = configparser.ConfigParser()
>>> config.read_file(open('review-stats.cfg'))
>>> config.sections()
['global']
>>> config2 = configparser.ConfigParser()
>>> f = open('review-stats.cfg')
>>> f
<_io.TextIOWrapper name='review-stats.cfg' mode='r' encoding='UTF-8'>
>>> config2.read_file(f)
>>> config2.sections()
['global']


python
Python 3.8.0 (default, Nov  6 2019, 21:49:08) 
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import configparser
>>> config = configparser.ConfigParser()
>>> config.read_file(open('review-stats.cfg'))
>>> config.sections()
['global']
>>> config2 = configparser.ConfigParser()
>>> f = open('review-stats.cfg')
>>> f
<_io.TextIOWrapper name='review-stats.cfg' mode='r' encoding='UTF-8'>
>>> config2.read_file(f)
>>> config2.sections()
['global']
>>> config3 = configparser.ConfigParser()
>>> config3.read_file(f) # This wouldn't work since f.read() is '' and has reached file end.
>>> config3.sections()
[]
>>>

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39387>
_______________________________________

From report at bugs.python.org  Sun Jan 19 10:28:05 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Jan 2020 15:28:05 +0000
Subject: [issue39385] Add an assertNoLogs context manager to unittest TestCase
In-Reply-To: <1579379123.37.0.908861475494.issue39385@roundup.psfhosted.org>
Message-ID: <1579447685.1.0.880764871694.issue39385@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39385>
_______________________________________

From report at bugs.python.org  Sun Jan 19 11:08:33 2020
From: report at bugs.python.org (Mattia Verga)
Date: Sun, 19 Jan 2020 16:08:33 +0000
Subject: [issue39387] configparser read_file() with variable
In-Reply-To: <1579438762.29.0.201953236535.issue39387@roundup.psfhosted.org>
Message-ID: <1579450113.67.0.0296385563458.issue39387@roundup.psfhosted.org>


Mattia Verga <mattia.verga at gmail.com> added the comment:

I started trying to reproduce this with different Python interpreters and I've found it now works as expected also with the original one (BTW it was CPython 3.7.6).
I really don't know why it didn't work before. Sorry for the noise.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39387>
_______________________________________

From report at bugs.python.org  Sun Jan 19 11:14:50 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 19 Jan 2020 16:14:50 +0000
Subject: [issue29435] Allow to pass fileobj to is_tarfile
In-Reply-To: <1486132653.21.0.166387912558.issue29435@psf.upfronthosting.co.za>
Message-ID: <1579450490.81.0.972988168369.issue29435@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +ethan.furman, xtreak
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29435>
_______________________________________

From report at bugs.python.org  Sun Jan 19 11:30:34 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 19 Jan 2020 16:30:34 +0000
Subject: [issue39134] can't construct dataclass as ABC (or runtime check as
 data protocol)
In-Reply-To: <1577318740.46.0.10314451567.issue39134@roundup.psfhosted.org>
Message-ID: <1579451434.59.0.0556860541094.issue39134@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

In the example, it should be `int`, right?

Anyway, the bug tracker is not a good place to get questions answered. Since this is mostly about type checking, I recommend that you try this Gitter instance: https://gitter.im/python/typing

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39134>
_______________________________________

From report at bugs.python.org  Sun Jan 19 12:20:13 2020
From: report at bugs.python.org (Adorilson Bezerra)
Date: Sun, 19 Jan 2020 17:20:13 +0000
Subject: [issue38558] Data Structures documentation out of sync with new
 Walrus operator
In-Reply-To: <1571776032.37.0.709698360286.issue38558@roundup.psfhosted.org>
Message-ID: <1579454413.39.0.582750356563.issue38558@roundup.psfhosted.org>


Change by Adorilson Bezerra <adorilson at gmail.com>:


----------
pull_requests: +17458
pull_request: https://github.com/python/cpython/pull/16973

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38558>
_______________________________________

From report at bugs.python.org  Sun Jan 19 12:21:16 2020
From: report at bugs.python.org (Kit Yan Choi)
Date: Sun, 19 Jan 2020 17:21:16 +0000
Subject: [issue39385] Add an assertNoLogs context manager to unittest TestCase
In-Reply-To: <1579379123.37.0.908861475494.issue39385@roundup.psfhosted.org>
Message-ID: <1579454476.38.0.0558466146184.issue39385@roundup.psfhosted.org>


Change by Kit Yan Choi <kit at kychoi.org>:


----------
keywords: +patch
pull_requests: +17459
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18067

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39385>
_______________________________________

From report at bugs.python.org  Sun Jan 19 12:26:54 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 19 Jan 2020 17:26:54 +0000
Subject: [issue39388] IDLE: Changes to keybindings aren't reverted on cancel
Message-ID: <1579454814.83.0.214082959531.issue39388@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

In https://bugs.python.org/issue35598#msg332634, Terry mentioned a bug when updating the configuration of a key, but then cancelling out of configdialog.

> Change a key binding.  Cancel. Re-open config dialog.  Try to change back.  It says original binding is in use -- which it is if one closes IDLE and reopens, or opens a different instance.  It seems that cancel is not properly undoing the temporary change.

----------
assignee: terry.reedy
components: IDLE
messages: 360262
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Changes to keybindings aren't reverted on cancel
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39388>
_______________________________________

From report at bugs.python.org  Sun Jan 19 12:29:34 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 19 Jan 2020 17:29:34 +0000
Subject: [issue39388] IDLE: Changes to keybindings aren't reverted on cancel
In-Reply-To: <1579454814.83.0.214082959531.issue39388@roundup.psfhosted.org>
Message-ID: <1579454974.26.0.211144886824.issue39388@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch
pull_requests: +17460
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18068

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39388>
_______________________________________

From report at bugs.python.org  Sun Jan 19 13:09:52 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 19 Jan 2020 18:09:52 +0000
Subject: [issue34780] Hang on startup if stdin refers to a pipe with an
 outstanding concurrent operation on Windows
In-Reply-To: <1537732835.69.0.956365154283.issue34780@psf.upfronthosting.co.za>
Message-ID: <1579457392.82.0.88291548508.issue34780@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
versions: +Python 3.9 -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34780>
_______________________________________

From report at bugs.python.org  Sun Jan 19 13:14:28 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 19 Jan 2020 18:14:28 +0000
Subject: [issue34834] test_ssl.test_options does not correctly account for
 built-in ctx defaults with openssl 1.1.1
In-Reply-To: <1538151296.99.0.545547206417.issue34834@psf.upfronthosting.co.za>
Message-ID: <1579457668.5.0.507667895012.issue34834@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As this issue appears to only affect 2.7 which recently reached end-of-life status, I'm going to go ahead and close it.

----------
assignee:  -> christian.heimes
components: +SSL, Tests
nosy: +zach.ware
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34834>
_______________________________________

From report at bugs.python.org  Sun Jan 19 13:17:44 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 19 Jan 2020 18:17:44 +0000
Subject: [issue24658] open().write() and .read() fails on 2 GB+ data (OS X)
In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za>
Message-ID: <1579457864.76.0.0230076785821.issue24658@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Since 3.x is fixed and 2.7 has reached EOL, I'm closing the issue.  Thanks for getting it fixed in 3.x, Stephane and Victor!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24658>
_______________________________________

From report at bugs.python.org  Sun Jan 19 13:17:57 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 19 Jan 2020 18:17:57 +0000
Subject: [issue24658] open().write() and .read() fails on 2 GB+ data (OS X)
In-Reply-To: <1437188368.42.0.0977367912313.issue24658@psf.upfronthosting.co.za>
Message-ID: <1579457877.64.0.110766105277.issue24658@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24658>
_______________________________________

From report at bugs.python.org  Sun Jan 19 13:21:29 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 19 Jan 2020 18:21:29 +0000
Subject: [issue34145] uuid3 and uuid5 hard to use portably between Python 2
 and 3
In-Reply-To: <1531903567.77.0.56676864532.issue34145@psf.upfronthosting.co.za>
Message-ID: <1579458089.63.0.101009864847.issue34145@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Python 2.7 has reached EOL, and so this change can no longer be made.  Thanks for the idea report and idea anyway, Bence!

----------
nosy: +zach.ware
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34145>
_______________________________________

From report at bugs.python.org  Sun Jan 19 13:51:39 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 19 Jan 2020 18:51:39 +0000
Subject: [issue39146] too much memory consumption in re.compile unicode
In-Reply-To: <1577524829.3.0.724432739165.issue39146@roundup.psfhosted.org>
Message-ID: <1579459899.83.0.930342124506.issue39146@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As mentioned on the attached PR, Python 2.7 has reached EOL and this can no longer be accepted.  Thanks for the report and patch anyway!

----------
nosy: +zach.ware
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39146>
_______________________________________

From report at bugs.python.org  Sun Jan 19 13:55:54 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 19 Jan 2020 18:55:54 +0000
Subject: [issue29612] TarFile.extract() suffers from hard links inside tarball
In-Reply-To: <1487671846.82.0.103027933595.issue29612@psf.upfronthosting.co.za>
Message-ID: <1579460154.8.0.188137433128.issue29612@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +ethan.furman
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29612>
_______________________________________

From report at bugs.python.org  Sun Jan 19 14:00:52 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 19 Jan 2020 19:00:52 +0000
Subject: [issue36417] unicode.isdecimal bug in online Python 2 documentation
In-Reply-To: <1553438833.3.0.95385374587.issue36417@roundup.psfhosted.org>
Message-ID: <1579460452.67.0.698102367309.issue36417@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As Python 2.7 has reached EOL and the branch is closed to regular maintenance, I'm closing the issue.  Thanks for the report and patch anyway!

----------
nosy: +zach.ware
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36417>
_______________________________________

From report at bugs.python.org  Sun Jan 19 15:23:58 2020
From: report at bugs.python.org (William Chargin)
Date: Sun, 19 Jan 2020 20:23:58 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
Message-ID: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>


New submission from William Chargin <wchargin at gmail.com>:

The `gzip` module properly uses the user-specified compression level to
control the underlying zlib stream compression level, but always writes
metadata that indicates that the maximum compression level was used.

Repro:

```
import gzip

blob = b"The quick brown fox jumps over the lazy dog." * 32

with gzip.GzipFile("fast.gz", mode="wb", compresslevel=1) as outfile:
    outfile.write(blob)

with gzip.GzipFile("best.gz", mode="wb", compresslevel=9) as outfile:
    outfile.write(blob)
```

Run this script, then run `wc -c *.gz` and `file *.gz`:

```
$ wc -c *.gz
 82 best.gz
 84 fast.gz
166 total
$ file *.gz
best.gz: gzip compressed data, was "best", last modified: Sun Jan 19 20:15:23 2020, max compression
fast.gz: gzip compressed data, was "fast", last modified: Sun Jan 19 20:15:23 2020, max compression
```

The file sizes correctly reflect the difference, but `file` thinks that
both archives are written at max compression.

The error is that the ninth byte of the header in the output stream is
hard-coded to `\002` at Lib/gzip.py:260 (as of 558f07891170), which
indicates maximum compression. The correct value to indicate maximum
speed is `\004`. See RFC 1952, section 2.3.1:
<https://tools.ietf.org/html/rfc1952>

Using GNU `gzip(1)` with `--fast` creates the same output file as the
one emitted by the `gzip` module, except for two bytes: the metadata and
the OS (the ninth and tenth bytes).

----------
components: Library (Lib)
files: repro.py
messages: 360268
nosy: wchargin
priority: normal
severity: normal
status: open
title: gzip metadata fails to reflect compresslevel
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48853/repro.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Sun Jan 19 15:24:33 2020
From: report at bugs.python.org (William Chargin)
Date: Sun, 19 Jan 2020 20:24:33 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579465473.72.0.978142553221.issue39389@roundup.psfhosted.org>


Change by William Chargin <wchargin at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Sun Jan 19 15:26:59 2020
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 19 Jan 2020 20:26:59 +0000
Subject: [issue39373] --
In-Reply-To: <1579312844.33.0.404228365742.issue39373@roundup.psfhosted.org>
Message-ID: <1579465619.88.0.455084181616.issue39373@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: new world -> --

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39373>
_______________________________________

From report at bugs.python.org  Sun Jan 19 15:27:07 2020
From: report at bugs.python.org (William Chargin)
Date: Sun, 19 Jan 2020 20:27:07 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579465627.31.0.6064138698.issue39389@roundup.psfhosted.org>


William Chargin <wchargin at gmail.com> added the comment:

(The commit reference above was meant to be git558f07891170, not a
Mercurial reference. Pardon the churn; I'm new here. :-) )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Sun Jan 19 15:27:16 2020
From: report at bugs.python.org (Bernhard M. Wiedemann)
Date: Sun, 19 Jan 2020 20:27:16 +0000
Subject: [issue34990] year 2038 problem in compileall.py
In-Reply-To: <1539602536.3.0.788709270274.issue34990@psf.upfronthosting.co.za>
Message-ID: <1579465636.36.0.437261837306.issue34990@roundup.psfhosted.org>


Bernhard M. Wiedemann <pythonbugs at lsmod.de> added the comment:

ping.
Another 19th of January passed.

I'd still like to see progress on this, because this hinders my other y2038 bug discovery work.

----------
versions: +Python 3.5, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34990>
_______________________________________

From report at bugs.python.org  Sun Jan 19 15:40:46 2020
From: report at bugs.python.org (Manuel Barkhau)
Date: Sun, 19 Jan 2020 20:40:46 +0000
Subject: [issue39390] shutil.copytree - ignore callback behaviour change
Message-ID: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>


New submission from Manuel Barkhau <mbarkhau at gmail.com>:

In Python 3.8, the types of the parameters to the ignore callable appear to have changed.

Previously the `src` parameter was a string and the `names` parameter was a list of strings. Now the `src` parameter appears to be either a `pathlib.Path` or an `os.DirEntry`, while the `names` parameter is a set of strings.

I would suggest adding the following to the documentation https://github.com/python/cpython/blob/master/Doc/library/shutil.rst

   .. versionchanged:: 3.8
      The types of arguments to *ignore* have changed. The first argument 
      (the directory being visited) is a func:`os.DirEntry` or a 
      func:`pathlib.Path`; Previously it was a string. The second argument is
      a set of strings; previously it was a list of strings.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 360271
nosy: docs at python, mbarkhau
priority: normal
severity: normal
status: open
title: shutil.copytree - ignore callback behaviour change
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Sun Jan 19 15:47:19 2020
From: report at bugs.python.org (Manuel Barkhau)
Date: Sun, 19 Jan 2020 20:47:19 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579466839.69.0.107388764758.issue39390@roundup.psfhosted.org>


Change by Manuel Barkhau <mbarkhau at gmail.com>:


----------
title: shutil.copytree - ignore callback behaviour change -> shutil.copytree - 3.8 changed argument types of the ignore callback

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Sun Jan 19 16:04:09 2020
From: report at bugs.python.org (Manuel Barkhau)
Date: Sun, 19 Jan 2020 21:04:09 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579467849.27.0.393318913381.issue39390@roundup.psfhosted.org>


Change by Manuel Barkhau <mbarkhau at gmail.com>:


----------
keywords: +patch
pull_requests: +17462
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18069

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Sun Jan 19 16:40:21 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 19 Jan 2020 21:40:21 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
In-Reply-To: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>
Message-ID: <1579470021.9.0.669885864231.issue39374@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Go ahead and make a PR for this:

   function -> function (or other callable)

Let's keep the word "function" because it does a much better job of communicating that an the more abstract word "callable".

----------
assignee: docs at python -> rhettinger
priority: normal -> low
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39374>
_______________________________________

From report at bugs.python.org  Sun Jan 19 17:34:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jan 2020 22:34:15 +0000
Subject: [issue39379] sys.path[0] is already absolute path
In-Reply-To: <1579333617.11.0.372896670301.issue39379@roundup.psfhosted.org>
Message-ID: <1579473255.19.0.740921641775.issue39379@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Correct, it seems like sys.path[0] was already absolute and so it can be removed from What's New in Python 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39379>
_______________________________________

From report at bugs.python.org  Sun Jan 19 17:38:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jan 2020 22:38:51 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1579473531.04.0.530525858925.issue35561@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d8ef64422a75f40cecdb1a7ee43492607d3daaf6 by Victor Stinner (Zackery Spytz) in branch 'master':
bpo-35561: Supress valgrind false alarm on epoll_ctl(event) (GH-18060)
https://github.com/python/cpython/commit/d8ef64422a75f40cecdb1a7ee43492607d3daaf6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35561>
_______________________________________

From report at bugs.python.org  Sun Jan 19 17:39:02 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jan 2020 22:39:02 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1579473542.23.0.485695194932.issue35561@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17463
pull_request: https://github.com/python/cpython/pull/18070

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35561>
_______________________________________

From report at bugs.python.org  Sun Jan 19 17:39:08 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jan 2020 22:39:08 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1579473548.01.0.549930182848.issue35561@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17464
pull_request: https://github.com/python/cpython/pull/18071

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35561>
_______________________________________

From report at bugs.python.org  Sun Jan 19 17:40:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jan 2020 22:40:28 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1579473628.83.0.783454649969.issue35561@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Nikolaus Rath for the bug report, and thnaks Zackery Spytz for the fix!

The fix will be backported automatically to 3.7 and 3.8 as soon as CI tests pass.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35561>
_______________________________________

From report at bugs.python.org  Sun Jan 19 17:44:07 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jan 2020 22:44:07 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1579473847.51.0.321897645109.issue35561@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 296383b6d05f9617283aeb5b601106f84b016198 by Miss Islington (bot) in branch '3.7':
bpo-35561: Supress valgrind false alarm on epoll_ctl(event) (GH-18060)
https://github.com/python/cpython/commit/296383b6d05f9617283aeb5b601106f84b016198


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35561>
_______________________________________

From report at bugs.python.org  Sun Jan 19 17:44:39 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jan 2020 22:44:39 +0000
Subject: [issue35561] Valgrind reports Syscall param epoll_ctl(event) points
 to uninitialised byte(s)
In-Reply-To: <1545492162.72.0.0770528567349.issue35561@roundup.psfhosted.org>
Message-ID: <1579473879.56.0.616561151774.issue35561@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 23793edf0d61aa98478541d0ff8f2b900ff1813d by Miss Islington (bot) in branch '3.8':
bpo-35561: Supress valgrind false alarm on epoll_ctl(event) (GH-18060)
https://github.com/python/cpython/commit/23793edf0d61aa98478541d0ff8f2b900ff1813d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35561>
_______________________________________

From report at bugs.python.org  Sun Jan 19 18:03:57 2020
From: report at bugs.python.org (Peter Occil)
Date: Sun, 19 Jan 2020 23:03:57 +0000
Subject: [issue39391] Nondeterministic Pydoc output on functions that have
 functions as default parameters
Message-ID: <1579475037.48.0.632958566945.issue39391@roundup.psfhosted.org>


New submission from Peter Occil <poccil14 at gmail.com>:

It appears that if a method has default parameters set to functions, as in this example:

    def f1():
        pass

    def f2(a, b=f1):
        pass

The resulting Pydoc output produces a different, nondeterministic rendering for the f2 method each time it generates the documentation, such as `m1(a, b=<function f1 at 0x7f4ff67f8950>)` or `m1(a, b=<function f1 at 0x7f4ff67f8950>)`.  And this is problematic for version control systems, among other things, especially since this is not a meaningful change to the documentation.

One solution may be to write, say, `m1(a, b=f1)` instead.

----------
assignee: docs at python
components: Documentation
messages: 360278
nosy: Peter Occil, docs at python
priority: normal
severity: normal
status: open
title: Nondeterministic Pydoc output on functions that have functions as default parameters
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39391>
_______________________________________

From report at bugs.python.org  Sun Jan 19 18:05:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 19 Jan 2020 23:05:37 +0000
Subject: [issue34780] [Windows] Hang on startup if stdin refers to a pipe with
 an outstanding concurrent operation on Windows
In-Reply-To: <1537732835.69.0.956365154283.issue34780@psf.upfronthosting.co.za>
Message-ID: <1579475137.87.0.587467903655.issue34780@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Hang on startup if stdin refers to a pipe with an outstanding concurrent operation on Windows -> [Windows] Hang on startup if stdin refers to a pipe with an outstanding concurrent operation on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34780>
_______________________________________

From report at bugs.python.org  Sun Jan 19 18:21:30 2020
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Sun, 19 Jan 2020 23:21:30 +0000
Subject: [issue38400] Python segfaults when configured with --with-pydebug
 --with-trace-refs
In-Reply-To: <1570489297.7.0.2347429078.issue38400@roundup.psfhosted.org>
Message-ID: <1579476090.84.0.867126402873.issue38400@roundup.psfhosted.org>


Elvis Pranskevichus <elvis at magic.io> added the comment:

Since https://bugs.python.org/issue38070 was backported to 3.8, shouldn't this as well?  3.8 is currently broken otherwise.

----------
nosy: +Elvis.Pranskevichus

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38400>
_______________________________________

From report at bugs.python.org  Sun Jan 19 18:25:31 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jan 2020 23:25:31 +0000
Subject: [issue38400] Python segfaults when configured with --with-pydebug
 --with-trace-refs
In-Reply-To: <1570489297.7.0.2347429078.issue38400@roundup.psfhosted.org>
Message-ID: <1579476331.44.0.322602530125.issue38400@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17465
pull_request: https://github.com/python/cpython/pull/18072

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38400>
_______________________________________

From report at bugs.python.org  Sun Jan 19 18:25:37 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jan 2020 23:25:37 +0000
Subject: [issue38400] Python segfaults when configured with --with-pydebug
 --with-trace-refs
In-Reply-To: <1570489297.7.0.2347429078.issue38400@roundup.psfhosted.org>
Message-ID: <1579476337.51.0.542673031021.issue38400@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17466
pull_request: https://github.com/python/cpython/pull/18073

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38400>
_______________________________________

From report at bugs.python.org  Sun Jan 19 18:39:26 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 19 Jan 2020 23:39:26 +0000
Subject: [issue38400] Python segfaults when configured with --with-pydebug
 --with-trace-refs
In-Reply-To: <1570489297.7.0.2347429078.issue38400@roundup.psfhosted.org>
Message-ID: <1579477166.8.0.500376966413.issue38400@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Since https://bugs.python.org/issue38070 was backported to 3.8, shouldn't this as well?  3.8 is currently broken otherwise.

Thanks for the catch, Elvis!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38400>
_______________________________________

From report at bugs.python.org  Sun Jan 19 18:43:16 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jan 2020 23:43:16 +0000
Subject: [issue38400] Python segfaults when configured with --with-pydebug
 --with-trace-refs
In-Reply-To: <1570489297.7.0.2347429078.issue38400@roundup.psfhosted.org>
Message-ID: <1579477396.61.0.589171100745.issue38400@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a360070121836dd29b691f5d6d14bcfb371d8029 by Miss Islington (bot) in branch '3.7':
bpo-38400 Don't check for NULL linked list pointers in _PyObject_IsFreed (GH-16630)
https://github.com/python/cpython/commit/a360070121836dd29b691f5d6d14bcfb371d8029


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38400>
_______________________________________

From report at bugs.python.org  Sun Jan 19 18:43:41 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 19 Jan 2020 23:43:41 +0000
Subject: [issue38400] Python segfaults when configured with --with-pydebug
 --with-trace-refs
In-Reply-To: <1570489297.7.0.2347429078.issue38400@roundup.psfhosted.org>
Message-ID: <1579477421.44.0.694602075956.issue38400@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4cdb75890abd4ee7694744d5c24248f6735b0534 by Miss Islington (bot) in branch '3.8':
bpo-38400 Don't check for NULL linked list pointers in _PyObject_IsFreed (GH-16630)
https://github.com/python/cpython/commit/4cdb75890abd4ee7694744d5c24248f6735b0534


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38400>
_______________________________________

From report at bugs.python.org  Sun Jan 19 18:51:01 2020
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Sun, 19 Jan 2020 23:51:01 +0000
Subject: [issue38400] Python segfaults when configured with --with-pydebug
 --with-trace-refs
In-Reply-To: <1570489297.7.0.2347429078.issue38400@roundup.psfhosted.org>
Message-ID: <1579477861.65.0.442768844054.issue38400@roundup.psfhosted.org>


Elvis Pranskevichus <elvis at magic.io> added the comment:

Thanks for the lightning-fast turnaround, Pablo!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38400>
_______________________________________

From report at bugs.python.org  Sun Jan 19 21:56:55 2020
From: report at bugs.python.org (random832)
Date: Mon, 20 Jan 2020 02:56:55 +0000
Subject: [issue39365] Support (SEEK_END/SEEK_CUR) relative seeking in StringIO
In-Reply-To: <1579234995.29.0.127298904142.issue39365@roundup.psfhosted.org>
Message-ID: <1579489015.49.0.689622990215.issue39365@roundup.psfhosted.org>


random832 <random832 at fastmail.us> added the comment:

That documentation isn't specific to StringIO, and in any case, the limitation in question isn't documented. The actual implementation is at https://github.com/python/cpython/blob/HEAD/Modules/_io/stringio.c#L484

But if examples would help, they're simple to come up with:

>>> f = io.StringIO('t\xe9st')
>>> f.seek(-1, io.SEEK_END)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: Can't do nonzero cur-relative seeks
>>> f.seek(2, io.SEEK_CUR)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: Can't do nonzero cur-relative seeks
# demonstration that SEEK_SET works treating all characters as one unit
>>> f.seek(2, io.SEEK_SET)
2
>>> f.read()
'st'

As far as I know this is the case in all currently maintained versions of Python 3, since the C-based unicode StringIO implementation was added in 2008.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39365>
_______________________________________

From report at bugs.python.org  Sun Jan 19 22:02:16 2020
From: report at bugs.python.org (Mark Sapiro)
Date: Mon, 20 Jan 2020 03:02:16 +0000
Subject: [issue27321] Email parser creates a message object that can't be
 flattened
In-Reply-To: <1465930372.53.0.0254623453508.issue27321@psf.upfronthosting.co.za>
Message-ID: <1579489336.64.0.34760087339.issue27321@roundup.psfhosted.org>


Change by Mark Sapiro <mark at msapiro.net>:


----------
pull_requests: +17467
pull_request: https://github.com/python/cpython/pull/18074

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27321>
_______________________________________

From report at bugs.python.org  Sun Jan 19 22:26:42 2020
From: report at bugs.python.org (Ryan Govostes)
Date: Mon, 20 Jan 2020 03:26:42 +0000
Subject: [issue20126] sched doesn't handle events added after scheduler starts
In-Reply-To: <1388890823.36.0.322424274213.issue20126@psf.upfronthosting.co.za>
Message-ID: <1579490802.3.0.300139746632.issue20126@roundup.psfhosted.org>


Ryan Govostes <rgovostes at gmail.com> added the comment:

This absolutely should be documented. If adding an earlier event is not supported then it should raise an exception. Appearing the enqueue the event but not triggering the callback is especially confusing. It may be obvious behavior to someone who has spent time developing this module or working with it but not to someone who just wants to, e.g., build an alarm clock or calendar app.

----------
nosy: +rgov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20126>
_______________________________________

From report at bugs.python.org  Sun Jan 19 22:45:59 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jan 2020 03:45:59 +0000
Subject: [issue38536] Trailing space in formatted currency with
 international=True and symbol following value
In-Reply-To: <1571561912.94.0.419750510226.issue38536@roundup.psfhosted.org>
Message-ID: <1579491959.86.0.756344551035.issue38536@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset e96d954527aa376457451e32a9d75ae3ea9ab4bd by Inada Naoki in branch 'master':
bpo-38536: locale: Remove trailing space in formatted currency (GH-16864)
https://github.com/python/cpython/commit/e96d954527aa376457451e32a9d75ae3ea9ab4bd


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38536>
_______________________________________

From report at bugs.python.org  Sun Jan 19 22:50:30 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jan 2020 03:50:30 +0000
Subject: [issue38536] Trailing space in formatted currency with
 international=True and symbol following value
In-Reply-To: <1571561912.94.0.419750510226.issue38536@roundup.psfhosted.org>
Message-ID: <1579492230.25.0.00559049148412.issue38536@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I'm not sure this fix should be backported.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38536>
_______________________________________

From report at bugs.python.org  Sun Jan 19 23:02:20 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jan 2020 04:02:20 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579492940.23.0.052484332998.issue39377@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +17468
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18075

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Sun Jan 19 23:27:14 2020
From: report at bugs.python.org (Matthew Fernandez)
Date: Mon, 20 Jan 2020 04:27:14 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1579494434.63.0.879049513755.issue3770@roundup.psfhosted.org>


Matthew Fernandez <matthew.fernandez at gmail.com> added the comment:

I'm trying to follow the history of this issue, as it does not seem fully resolved to me. While trying to package something for Debian, one of the buildd [0] logs for hurd-i386 points to this issue as the cause of a failure [1]. This occurs with Python 3.7, though Debian's Python 3.7 may involve some distro patches on top of upstream source. If the build log is inaccessible or incomprehensible, the relevant sections are:

    ...
    The following additional packages will be installed:
    ... libpython3-stdlib libpython3.7-minimal libpython3.7-stdlib ... python3 python3-minimal python3.7 python3.7-minimal
    ...
    /usr/bin/ctest --force-new-ctest-process -j1
    Test project /<<PKGBUILDDIR>>/obj-i686-gnu
        Start 1: tests
    1/1 Test #1: tests ............................***Failed    0.10 sec
    Traceback (most recent call last):
      File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 28, in <module>
        from _multiprocessing import SemLock, sem_unlink
    ImportError: cannot import name 'SemLock' from '_multiprocessing' (/usr/lib/python3.7/lib-dynload/_multiprocessing.cpython-37m-i386-gnu.so)

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "/<<PKGBUILDDIR>>/tests/run-tests.py", line 46, in <module>
        print_lock = multiprocessing.Lock()
      File "/usr/lib/python3.7/multiprocessing/context.py", line 66, in Lock
        from .synchronize import Lock
      File "/usr/lib/python3.7/multiprocessing/synchronize.py", line 32, in <module>
        " synchronization primitives needed will not" +
    ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.

Do you know what is happening here? Maybe the compounded ImportError I'm seeing *was* the resolution referred to in prior comments, but if so it seems strange to reference this issue in the error message.

The hurd-i386 platform is not a priority for me, so if the answer is "multiprocessing doesn't work there" I am perfectly OK with this. Also I realise I am asking you to recall >10 year old memories so I apologise in advance for any re-opened wounds.

If you need to see the source for what buildd is actually testing here, it's the debian/v2020.11.01-1 tag of [2].

  [0]: https://wiki.debian.org/buildd
  [1]: https://buildd.debian.org/status/fetch.php?pkg=rumur&arch=hurd-i386&ver=2020.01.11-1&stamp=1579290012&raw=0
  [2]: https://github.com/Smattr/rumur

----------
nosy: +smattr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Sun Jan 19 23:54:08 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jan 2020 04:54:08 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579496048.15.0.0151910263744.issue39377@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 5492bfcefec67b016e8239c0e9135bc2f03e3058 by Inada Naoki in branch 'master':
bpo-39377: json: Remove the encoding option. (GH-18075)
https://github.com/python/cpython/commit/5492bfcefec67b016e8239c0e9135bc2f03e3058


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Sun Jan 19 23:54:18 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jan 2020 04:54:18 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579496058.96.0.291566541223.issue39377@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Mon Jan 20 00:07:43 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jan 2020 05:07:43 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579496863.39.0.997612583176.issue39377@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +17469
pull_request: https://github.com/python/cpython/pull/18076

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Mon Jan 20 00:14:23 2020
From: report at bugs.python.org (Lijo)
Date: Mon, 20 Jan 2020 05:14:23 +0000
Subject: [issue39392] Python Turtle is not filling alternate overlapping areas
 of a shape with same color
Message-ID: <1579497263.75.0.682788787706.issue39392@roundup.psfhosted.org>


New submission from Lijo <lijo-jose at outlook.com>:

Alternate overlapping areas of shape are not getting filled with same color. But instead its white.
Reproducible code

from turtle import *
color('black', 'yellow')    
begin_fill()
circle(40)
circle(60)
circle(80)
end_fill()

Generated image ubuntu at python3.7.4
https://ibb.co/jG0bCBz

Raised a stackoverflow question
https://stackoverflow.com/questions/59811915/python-turtle-is-not-filling-alternate-overlapping-areas-of-a-shape-with-same-co

----------
components: Tkinter
messages: 360290
nosy: lijose
priority: normal
severity: normal
status: open
title: Python Turtle is not filling alternate overlapping areas of a shape with same color
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39392>
_______________________________________

From report at bugs.python.org  Mon Jan 20 00:36:14 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 20 Jan 2020 05:36:14 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579498574.21.0.831304986602.issue39377@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Should we be raising an error if encoding is present on 3.9 as part of kwargs? It's obtrusive but for people going from Python 3.7 to 3.9 there will be no change and they will keep assuming encoding parameter is valid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Mon Jan 20 01:08:56 2020
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 20 Jan 2020 06:08:56 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579500536.63.0.89294476675.issue39377@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Do you mean to say we should or shouldn't be raising an error? With Inada-san's change you get this:

>>> json.loads("true", encoding='utf8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\ammar\workspace\cpython\lib\json\__init__.py", line 359, in loads
    return cls(**kw).decode(s)
TypeError: __init__() got an unexpected keyword argument 'encoding'

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Mon Jan 20 01:24:18 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jan 2020 06:24:18 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579501458.76.0.63683047069.issue39377@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

If this broke some real-world software and the pain is high enough, we can revert the change and add one more deprecation period, like all other removals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Mon Jan 20 02:50:35 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 20 Jan 2020 07:50:35 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579506635.72.0.902171575289.issue39377@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> Do you mean to say we should or shouldn't be raising an error? With Inada-san's change you get this:

Sorry, I misread the patch as only removal and didn't test the change completely.

I am filing issues on code that I can find using this pattern and will wait for the feedback during alpha cycle.

* https://github.com/ansible/ansible/issues/66592
* https://github.com/jupyter/notebook/issues/5165
* https://github.com/django-extensions/django-extensions/issues/1465

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Mon Jan 20 02:54:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2020 07:54:32 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579506872.64.0.278397973986.issue39377@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reopen the issue.

> New changeset 5492bfcefec67b016e8239c0e9135bc2f03e3058 by Inada Naoki in branch 'master':
> bpo-39377: json: Remove the encoding option. (GH-18075)
> https://github.com/python/cpython/commit/5492bfcefec67b016e8239c0e9135bc2f03e3058

Would you mind to document the removal in the following doc section?
https://docs.python.org/dev/whatsnew/3.9.html#removed

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Mon Jan 20 03:13:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jan 2020 08:13:05 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579507985.93.0.909842510252.issue39377@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Please update the documentation which still mentions the encoding parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Mon Jan 20 03:22:33 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jan 2020 08:22:33 +0000
Subject: [issue39365] Support (SEEK_END/SEEK_CUR) relative seeking in StringIO
In-Reply-To: <1579234995.29.0.127298904142.issue39365@roundup.psfhosted.org>
Message-ID: <1579508553.45.0.422121141405.issue39365@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a duplicate of issue25190.

----------
components: +Library (Lib)
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Define StringIO seek offset as code point offset
type: behavior -> enhancement
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39365>
_______________________________________

From report at bugs.python.org  Mon Jan 20 03:23:34 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jan 2020 08:23:34 +0000
Subject: [issue29258] __init__.py required for pkgutil.walk_packages in python3
In-Reply-To: <1484282874.75.0.69511180509.issue29258@psf.upfronthosting.co.za>
Message-ID: <1579508614.59.0.042357511897.issue29258@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> PEP420 makes __init__.py files optional

This is almost wrong.  PEP 420 added a new way for "namespace pacakge."
PEP 420 doesn't make empty __init__.py file in regular package.

(See https://dev.to/methane/don-t-omit-init-py-3hga)

Then, should pkgutil.walk_packages walk into all directories (e.g.  node_modules) ?  I don't think so.

----------
nosy: +inada.naoki
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29258>
_______________________________________

From report at bugs.python.org  Mon Jan 20 03:29:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jan 2020 08:29:13 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579508953.6.0.37973052893.issue39389@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Looks reasonable. gzip should write b'\002' for compresslevel == _COMPRESS_LEVEL_BEST, b'\004' for compresslevel == _COMPRESS_LEVEL_FAST, and b'\000' otherwise. Do you mind to create a PR William.

----------
keywords: +easy
nosy: +serhiy.storchaka
stage:  -> needs patch
versions:  -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Mon Jan 20 03:31:24 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jan 2020 08:31:24 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579509084.69.0.571401301812.issue39390@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This looks like a backward incompatible change in 3.8. Should not copytree convert arguments of the ignore callback to str and list correspondingly?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Mon Jan 20 03:34:07 2020
From: report at bugs.python.org (Alberto N Leilani Campos)
Date: Mon, 20 Jan 2020 08:34:07 +0000
Subject: [issue39293] Windows 10 64-bit needs reboot after install
In-Reply-To: <1578690694.46.0.197073018811.issue39293@roundup.psfhosted.org>
Message-ID: <1579509247.66.0.435343915653.issue39293@roundup.psfhosted.org>


Change by Alberto N Leilani Campos <albertocampos1021 at gmail.com>:


Added file: https://bugs.python.org/file48854/windows-ssh-tools.snapshot.json

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39293>
_______________________________________

From report at bugs.python.org  Mon Jan 20 03:49:36 2020
From: report at bugs.python.org (William Chargin)
Date: Mon, 20 Jan 2020 08:49:36 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579510176.26.0.349078774106.issue39389@roundup.psfhosted.org>


Change by William Chargin <wchargin at gmail.com>:


----------
keywords: +patch
pull_requests: +17470
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18077

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Mon Jan 20 03:58:17 2020
From: report at bugs.python.org (William Chargin)
Date: Mon, 20 Jan 2020 08:58:17 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579510697.81.0.450626132868.issue39389@roundup.psfhosted.org>


William Chargin <wchargin at gmail.com> added the comment:

Sure, PR sent (pull_request17470).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Mon Jan 20 03:59:07 2020
From: report at bugs.python.org (William Chargin)
Date: Mon, 20 Jan 2020 08:59:07 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579510747.41.0.734511060135.issue39389@roundup.psfhosted.org>


William Chargin <wchargin at gmail.com> added the comment:

PR URL, for reference:
<https://github.com/python/cpython/pull/18077>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Mon Jan 20 04:04:32 2020
From: report at bugs.python.org (Manuel Barkhau)
Date: Mon, 20 Jan 2020 09:04:32 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579511072.81.0.726043167524.issue39390@roundup.psfhosted.org>


Manuel Barkhau <mbarkhau at gmail.com> added the comment:

> This looks like a backward incompatible change in 3.8.

Indeed. 

> Should not copytree convert arguments of the ignore callback to str and list correspondingly?

Well, since any existing code probably expects that behavior (or at least probably works if that is the case), I would be for such a change. I'm not sure what your policy is though. If there is recently written code that assumes the new types, are you OK with that breaking if it is changed back?

I guess since it's an undocumented breaking change, it shouldn't be too much of an issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Mon Jan 20 04:14:32 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jan 2020 09:14:32 +0000
Subject: [issue36892] "Modules" section in Tutorial contains incorrect
 description about __init__.py
In-Reply-To: <1557615601.14.0.911128255467.issue36892@roundup.psfhosted.org>
Message-ID: <1579511672.72.0.439440046899.issue36892@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I think it is just a noise for the tutorial readers.

I created a post about misunderstanding of PEP 420.
https://dev.to/methane/don-t-omit-init-py-3hga

How about adding note in top of the PEP 420 instead?

.. note::
   Namespace packages are not regular packages.  It
   is a feature for very special use case.
   Don't omit ``__init__.py`` in regular packages.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36892>
_______________________________________

From report at bugs.python.org  Mon Jan 20 04:27:30 2020
From: report at bugs.python.org (plimkilde)
Date: Mon, 20 Jan 2020 09:27:30 +0000
Subject: [issue39393] Misleading error message upon dependent DLL resolution
 failure
Message-ID: <1579512450.11.0.864670825995.issue39393@roundup.psfhosted.org>


New submission from plimkilde <peter.limkilde at gmail.com>:

Under Windows with Python 3.8+, trying to load a DLL whose dependencies cannot be resolved may produce a misleading error message.

For example, if we are trying to load a library foo.dll that depends on bar.dll, and bar.dll cannot be resolved while foo.dll itself can, Python gives this error message:
"FileNotFoundError: Could not find module 'foo.dll'. Try using the full path with constructor syntax."
(behavior introduced with PR #12302)

Personally, I'd be happy to see a fix that simply adds " (or one of its dependencies)" to the error message.

----------
components: Windows, ctypes
messages: 360305
nosy: paul.moore, plimkilde, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Misleading error message upon dependent DLL resolution failure
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39393>
_______________________________________

From report at bugs.python.org  Mon Jan 20 05:44:05 2020
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Mon, 20 Jan 2020 10:44:05 +0000
Subject: [issue39394] DeprecationWarning for `flag not at the start of
 expression` is cutoff too early
Message-ID: <1579517044.97.0.328160626256.issue39394@roundup.psfhosted.org>


New submission from J?rgen Gmach <juergen.gmach at googlemail.com>:

The usage of flags not at the start of an expression is deprecated.

Also see "Deprecate the use of flags not at the start of regular expression" / https://bugs.python.org/issue22493 

A deprecation warning is issued, but is cutoff at 20 characters.

For complex expressions this is way too small.

Example ( https://github.com/jedie/python-creole/issues/31 ):

current output

/home/jugmac00/Projects/bliss_deployment/work/_/home/jugmac00/.batou-shared-eggs/python_creole-1.3.2-py3.7.egg/creole/parser/creol2html_parser.py:48
  /home/jugmac00/Projects/bliss_deployment/work/_/home/jugmac00/.batou-shared-eggs/python_creole-1.3.2-py3.7.egg/creole/parser/creol2html_parser.py:48: DeprecationWarning: Flags not at the start of the expression '(?P<image>\n         ' (truncated)
    re.VERBOSE | re.UNICODE


output with patched sre_parse.py

creole/parser/creol2html_parser.py:51
  /home/jugmac00/Projects/python-creole/creole/parser/creol2html_parser.py:51: DeprecationWarning: Flags not at the start of the expression '\n            \\| \\s*\n            (\n                (?P<head> [=][^|]+ ) |\n                (?P<cell> (  (?P<link>\n            \\[\\[\n            (?P<link_target>.+?) \\s*\n            ([|] \\s* (?P<link_text>.+?) \\s*)?\n            ]]\n        )|\n        (?P<macro_inline>\n        << \\s* (?P<macro_inline_start>\\w+) \\s* (?P<macro_inline_args>.*?) \\s* >>\n        (?P<macro_inline_text>(.|\\n)*?)\n        <</ \\s* (?P=macro_inline_start) \\s* >>\n        )\n    |(?P<macro_tag>\n            <<(?P<macro_tag_name> \\w+) (?P<macro_tag_args>.*?) \\s* /*>>\n        )|(?i)(?P<image>\n            {{\n            (?P<image_target>.+?) \\s*\n            (\\| \\s* (?P<image_text>.+?) \\s*)?\n            }}\n        )|(?P<pre_inline> {{{ (?P<pre_inline_text>.*?) }}} ) | [^|])+ )\n            ) \\s*\n        '
    cell_re = re.compile(x, re.VERBOSE | re.UNICODE)


(Line number differs because there was a change in the source between these two test runs).

I would like to create a pr and remove the limitation to 20 characters completely, but wanted to get feedback before I do so.

The deprecation warning was created by Tim Graham - maybe he could elaborate why it was cut at 20 chars at first?
https://github.com/python/cpython/commit/abf275af5804c5f76fbe10c5cb1dd3d2e4b04c5b

----------
components: Regular Expressions
messages: 360306
nosy: ezio.melotti, jugmac00, mrabarnett
priority: normal
severity: normal
status: open
title: DeprecationWarning for `flag not at the start of expression` is cutoff too early
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39394>
_______________________________________

From report at bugs.python.org  Mon Jan 20 06:02:40 2020
From: report at bugs.python.org (Eric Wieser)
Date: Mon, 20 Jan 2020 11:02:40 +0000
Subject: [issue29258] __init__.py required for pkgutil.walk_packages in python3
In-Reply-To: <1484282874.75.0.69511180509.issue29258@psf.upfronthosting.co.za>
Message-ID: <1579518160.47.0.711800351703.issue29258@roundup.psfhosted.org>


Eric Wieser <wieser.eric at gmail.com> added the comment:

If the resolution here is that this is behaving as intended (which personally I disagree with), I think this issue should remain open as a documentation task - the docs should clearly state that this does not apply to PEP420 namespace packages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29258>
_______________________________________

From report at bugs.python.org  Mon Jan 20 06:54:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 20 Jan 2020 11:54:08 +0000
Subject: [issue39394] DeprecationWarning for `flag not at the start of
 expression` is cutoff too early
In-Reply-To: <1579517044.97.0.328160626256.issue39394@roundup.psfhosted.org>
Message-ID: <1579521248.44.0.259516076831.issue39394@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Why do you want to output the full regular expression? Is not source file path, line number, and starting 20 characters not enough to identify the affected regular expression?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39394>
_______________________________________

From report at bugs.python.org  Mon Jan 20 06:58:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2020 11:58:54 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
Message-ID: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

os.environ[key] = value has to keep internally the string "key=value\0" after putenv("key=value\0") has been called, since the glibc doesn't copy the string. Python has to manage the string memory.

Internally, the posix module uses a "posix_putenv_garbage" dictionary mapping key (bytes) to value (bytes). Values are "key=value\0" strings.

The bpo-35381 issue converted the os ("posix" in practice) module PEP 384: "Remove all static state from posixmodule": commit b3966639d28313809774ca3859a347b9007be8d2. The _posix_clear() function is now called by _PyImport_Cleanup().

Problem: the glibc is not aware that Python is exiting and that the memory of the environment variable has been released. Next access to environment variables ("environ" C variable, putenv, setenv, unsetenv, ...) can crash. Sometimes, it doesn't crash even if the memory has been released, because free() does not always dig immediately holes in the heap memory (the complex problelm of memory fragmentation).

The posix module should notify the glibc that the memory will be released before releasing the memory, to avoid keeping dangling pointers in the "environ" C variable.

The following crash in the Elements module is an example of crash introduced by commit b3966639d28313809774ca3859a347b9007be8d2 which introduced this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1791761

----------
components: Interpreter Core
messages: 360309
nosy: vstinner
priority: normal
severity: normal
status: open
title: The os module should unset() environment variable at exit
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Mon Jan 20 06:58:59 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jan 2020 11:58:59 +0000
Subject: [issue29258] __init__.py required for pkgutil.walk_packages in python3
In-Reply-To: <1484282874.75.0.69511180509.issue29258@psf.upfronthosting.co.za>
Message-ID: <1579521539.26.0.81816331882.issue29258@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
resolution: rejected -> 
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.8, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29258>
_______________________________________

From report at bugs.python.org  Mon Jan 20 06:59:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2020 11:59:41 +0000
Subject: [issue39394] re: DeprecationWarning for `flag not at the start of
 expression` is cutoff too early
In-Reply-To: <1579517044.97.0.328160626256.issue39394@roundup.psfhosted.org>
Message-ID: <1579521581.12.0.680290393409.issue39394@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: DeprecationWarning for `flag not at the start of expression` is cutoff too early -> re: DeprecationWarning for `flag not at the start of expression` is cutoff too early

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39394>
_______________________________________

From report at bugs.python.org  Mon Jan 20 07:16:18 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 20 Jan 2020 12:16:18 +0000
Subject: [issue29258] __init__.py required for pkgutil.walk_packages in python3
In-Reply-To: <1484282874.75.0.69511180509.issue29258@psf.upfronthosting.co.za>
Message-ID: <1579522578.76.0.758549078757.issue29258@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I am totally agree with Wolfgang:

> they make it impossible to know whether a directory found on the filesystem is *intended* as a Python package or not.

I think we shouldn't treat normal directory as namespace package until some portion in the directory is imported, or it is specified explicitly.

So walk_packages() should be used like:

  walk_packages("/path/to/namespace", "namespace")

I already rejected similar issue: #29642.

If you can not agree with me, please make an thread in python-dev ML or discuss.python.org.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29258>
_______________________________________

From report at bugs.python.org  Mon Jan 20 07:18:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2020 12:18:52 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579522732.12.0.946287868606.issue39395@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17471
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18078

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Mon Jan 20 07:19:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2020 12:19:25 +0000
Subject: [issue35381] posixmodule: convert statically allocated types
 (DirEntryType & ScandirIteratorType) to heap-allocated types
In-Reply-To: <1543818839.39.0.788709270274.issue35381@psf.upfronthosting.co.za>
Message-ID: <1579522765.67.0.47039843242.issue35381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue introduced a regression: bpo-39395 "The os module should unset() environment variable at exit".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35381>
_______________________________________

From report at bugs.python.org  Mon Jan 20 07:20:42 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 20 Jan 2020 12:20:42 +0000
Subject: [issue39396] AIX: math.nextafter(a, b) breaks AIX bot
Message-ID: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

As issue39288 (that introduces this breakage) is closed, opening a new issue.

Back from away - and only starting my investigation - and that will probably be slow. Have not done anything with IEEE754 in over 30 years.

----------
messages: 360312
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: AIX: math.nextafter(a, b) breaks AIX bot
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Mon Jan 20 07:23:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2020 12:23:12 +0000
Subject: [issue39396] AIX: math.nextafter(a, b) breaks AIX bot
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579522992.86.0.774484717786.issue39396@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> AIX: math.nextafter(a, b) breaks AIX bot

Please elaborate. What is the error?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Mon Jan 20 07:46:03 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 20 Jan 2020 12:46:03 +0000
Subject: [issue39396] AIX: math.nextafter(a, b) breaks AIX bot
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579524363.58.0.196971500861.issue39396@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

As I said, was investigating.

a) is a bug in most AIX system libraries.
b) there is a fix, but not one I can install - as my bots and build systems run on AIX 6.1 and AIX 7.1

c) the fix is APAR IV95512 which includes fixes in the following filesets:

IV95512 shipped  nextafter(+0.0, -0.0) returns +0.0 instead of -0.0.
      bos.rte.shell 7.2.2.0
      bos.adt.prof 7.2.2.0
      bos.adt.libm 7.2.2.0

So, nothing for me "to fix" -- see https://www-01.ibm.com/support/docview.wss?uid=isg1IV95512

FYI: The document URL (above) was last modified on 30 October 2017

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Mon Jan 20 07:57:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2020 12:57:02 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579525022.38.0.146712637234.issue39396@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ah, I saw an error on POWER6 AIX 3.x ("POWER6 (aka ppc64-be) using (GCC) 4.7.4"):
https://buildbot.python.org/all/#/builders/119/builds/175

The following test fails:

        self.assertEqualSign(math.nextafter(-0.0, +0.0), +0.0)

Well, C code specific to AIX can be added to nextafter() to handle this corner case:

diff --git a/Modules/mathmodule.c b/Modules/mathmodule.c
index 81d871786f..82ffb4c3d1 100644
--- a/Modules/mathmodule.c
+++ b/Modules/mathmodule.c
@@ -3287,7 +3287,16 @@ static PyObject *
 math_nextafter_impl(PyObject *module, double x, double y)
 /*[clinic end generated code: output=750c8266c1c540ce input=02b2d50cd1d9f9b6]*/
 {
-    double f = nextafter(x, y);
+    double f;
+#if defined(_AIX)
+    if (x == y) {
+        f = y;
+    }
+    else
+#endif
+    {
+        f = nextafter(x, y);
+    }
     return PyFloat_FromDouble(f);
 }
 

Another option is to not make the assumption on the libc nextafter() and handle x==y the same way on all platforms.

Error:

======================================================================
FAIL: test_nextafter (test.test_math.IsCloseTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_math.py", line 2040, in test_nextafter
    self.assertEqualSign(math.nextafter(-0.0, +0.0), +0.0)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_math.py", line 2018, in assertEqualSign
    self.assertEqual(math.copysign(1.0, x), math.copysign(1.0, y))
AssertionError: -1.0 != 1.0

Same error in test_cmath:

======================================================================
FAIL: test_nextafter (test.test_cmath.IsCloseTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_math.py", line 2040, in test_nextafter
    self.assertEqualSign(math.nextafter(-0.0, +0.0), +0.0)
  File "/home/buildbot/buildarea/3.x.aixtools-aix-power6/build/Lib/test/test_math.py", line 2018, in assertEqualSign
    self.assertEqual(math.copysign(1.0, x), math.copysign(1.0, y))
AssertionError: -1.0 != 1.0

----------
components: +Tests
nosy: +mark.dickinson
title: AIX: math.nextafter(a, b) breaks AIX bot -> AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0), +0.0) test fails on AIX

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Mon Jan 20 08:03:11 2020
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_Gmach?=)
Date: Mon, 20 Jan 2020 13:03:11 +0000
Subject: [issue39394] re: DeprecationWarning for `flag not at the start of
 expression` is cutoff too early
In-Reply-To: <1579517044.97.0.328160626256.issue39394@roundup.psfhosted.org>
Message-ID: <1579525391.78.0.735779249467.issue39394@roundup.psfhosted.org>


J?rgen Gmach <juergen.gmach at googlemail.com> added the comment:

> Why do you want to output the full regular expression?

The current output gives no clue about which flag is problematic, nor does it show the complete output (which at least would include the problematic flag), nor does it show the exact line, as it refers only to the line where compile gets called.

The warning points to following line ( https://github.com/jedie/python-creole/blob/4e74f29daaf5026a3d4d6dae9f2e74f5f3655439/creole/parser/creol2html_parser.py#L49-L50 ):

cell_re = re.compile(SpecialRules.cell, re.VERBOSE | re.UNICODE)


And SpecialRules.cell is a quite a big class ( https://github.com/jedie/python-creole/blob/4e74f29daaf5026a3d4d6dae9f2e74f5f3655439/creole/parser/creol2html_rules.py#L16-L97 ) defining lots of partial expressions.

Even if spotting this line ( https://github.com/jedie/python-creole/blob/4e74f29daaf5026a3d4d6dae9f2e74f5f3655439/creole/parser/creol2html_rules.py#L54 ) at the first glance it looks like it starts with the flag and should be correct (but is not as it turned out later).


> Is not source file path, line number, and starting 20 characters not enough to identify the affected regular expression?

It definitely was not enough for me (new to this code base as I only tried to report deprecation warnings in my application), and when you have a look at the comment ( https://github.com/jedie/python-creole/issues/31#issuecomment-575983117 ) it even was not enough for the author/maintainer of this package.

Do you expect any downside of printing the complete warning?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39394>
_______________________________________

From report at bugs.python.org  Mon Jan 20 08:08:42 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 20 Jan 2020 13:08:42 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579525722.92.0.184069887973.issue39396@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

A hard call to make, imho.

Thinking aloud...

Currently, for AIX 6.1 and AIX 7.1 your proposal for the code change would be great, but less so for AIX 7.2.

However! Since libm (on AIX) is a static library - the behavior depends on the support libm has on the build system.

I'll have to puzzle a bit with the configure process and figure out how to best determine the behavior of the build system. On a properly patched AIX 7.2 system the standard code would apply, on others the "adjusted behavior".

So, would you go for modified based on what version of libm is installed, better how this function is behaving?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Mon Jan 20 08:22:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2020 13:22:47 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579526567.87.0.972115319604.issue39396@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Checking how Python is linked or checking the libm version sounds overkill to me. "if (x == y)" test is really cheap: I don't expect nextafter() to be used in performance critical code path anyway. That's why I even consider to add this code path on all platforms, not only AIX.

Mark: what's your call on that one? Make the code conditional on AIX? In practice, it seems like only (old libm) AIX nextafter() requires to be "patched".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Mon Jan 20 09:04:41 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 20 Jan 2020 14:04:41 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579529081.24.0.0813702914264.issue39396@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

FYI: On AIX 5.3, after your proposal I get:

======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/prj/python/git/python3-3.9/Lib/test/test_cmath.py", line 418, in test_specific_values
    self.rAssertAlmostEqual(expected.imag, actual.imag,
  File "/data/prj/python/git/python3-3.9/Lib/test/test_cmath.py", line 130, in rAssertAlmostEqual
    self.fail(msg or 'zero has wrong sign: expected {!r}, '
AssertionError: exp0001: exp(complex(0.0, -0.0))
Expected: complex(1.0, -0.0)
Received: complex(1.0, 0.0)
Received value insufficiently close to expected value.

----------------------------------------------------------------------

So, test_nextafter works with the patch, but test_specific_values remains 'active'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Mon Jan 20 10:42:27 2020
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jan 2020 15:42:27 +0000
Subject: [issue39384] Email parser creates a message object that can't be
 flattened as bytes.
In-Reply-To: <1579376923.42.0.439623129413.issue39384@roundup.psfhosted.org>
Message-ID: <1579534947.75.0.777687400618.issue39384@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Since you parsed it as a string it is not really legitimate to serialize it as bytes.  (That will work if the input message only contains ascii, but not if it contains unicode).  You'll get the same error if you replace the garbage with the "?".  Using errors=replace is not crazy, but it hides the actual problem.  Let's see what other people think :)

In theory you could "fix" this by encoding the unicode using the charset specified by the container.  I have no idea how complicated it will be do that, and it would be a new feature: parsing strings is specified to only work with ASCII input, currently.

I put "fix" in quotes, because even if you make text parts like this example work, you still can't handle non-text 8bit mime parts.  Is it worth doing anyway?

Really, message_as_string and friends should just be avoided entirely, maybe even deprecated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39384>
_______________________________________

From report at bugs.python.org  Mon Jan 20 10:45:32 2020
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jan 2020 15:45:32 +0000
Subject: [issue39309] Please delete my account
In-Reply-To: <1579351769.04.0.498329028577.issue39309@roundup.psfhosted.org>
Message-ID: <1579535132.32.0.541256024697.issue39309@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

AFAIR it can only be done using the roundup command line on the server.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39309>
_______________________________________

From report at bugs.python.org  Mon Jan 20 10:57:36 2020
From: report at bugs.python.org (Sebastien Foo)
Date: Mon, 20 Jan 2020 15:57:36 +0000
Subject: [issue39397] Mac : fail to launch Python 3.8
Message-ID: <1579535856.72.0.329847745345.issue39397@roundup.psfhosted.org>


New submission from Sebastien Foo <sgandon at gmail.com>:

Hello,
I am facing an issue with python on mac and there is not much information that I can find to fix it.
When I installed the latest cli for Azure (brew upgrade azure-cli) it installed python 3.8
And then the az cli failed and running the python 3.8 failed too with the following error.
 
/usr/local/Cellar/python at 3.8/3.8.1/Frameworks/Python.framework/Versions/3.8/bin/python3.8
Fatal Python error: config_get_locale_encoding: failed to get the locale encoding: nl_langinfo(CODESET) failed
Python runtime state: preinitialized
 
I have tried to reinstall python and the azure cli without success.

Any help would be much appreciated.

----------
components: Installation
messages: 360322
nosy: Sebastien Foo
priority: normal
severity: normal
status: open
title: Mac : fail to launch Python 3.8
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39397>
_______________________________________

From report at bugs.python.org  Mon Jan 20 10:58:50 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 20 Jan 2020 15:58:50 +0000
Subject: [issue39397] Mac : fail to launch Python 3.8
In-Reply-To: <1579535856.72.0.329847745345.issue39397@roundup.psfhosted.org>
Message-ID: <1579535930.37.0.132171031868.issue39397@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39397>
_______________________________________

From report at bugs.python.org  Mon Jan 20 11:01:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2020 16:01:04 +0000
Subject: [issue39397] Mac : fail to launch Python 3.8
In-Reply-To: <1579535856.72.0.329847745345.issue39397@roundup.psfhosted.org>
Message-ID: <1579536064.47.0.00201847665672.issue39397@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39397>
_______________________________________

From report at bugs.python.org  Mon Jan 20 11:20:30 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 20 Jan 2020 16:20:30 +0000
Subject: [issue39393] Misleading error message upon dependent DLL resolution
 failure
In-Reply-To: <1579512450.11.0.864670825995.issue39393@roundup.psfhosted.org>
Message-ID: <1579537230.32.0.925715343473.issue39393@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

That clarification seems okay to me. The error message is in load_library in Modules/_ctypes/callproc.c. 

The underlying problem is that the directory of the DLL is only added to the search path (in CDLL.__init__ in Lib/ctypes/__init__.py) if the caller uses a qualified path. This is an OS limit that we can't avoid.

Also note that the suggestion to use a qualified path won't necessarily resolve the problem, in which case scripts will have to use os.add_dll_directory, and find a reliable way to identify the required directories.

----------
components: +Extension Modules
keywords: +easy (C)
nosy: +eryksun
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39393>
_______________________________________

From report at bugs.python.org  Mon Jan 20 12:14:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2020 17:14:25 +0000
Subject: [issue39398] AMD64 Fedora Rawhide Clang 3.x: C compiler cannot create
 executables
Message-ID: <1579540465.66.0.318494432862.issue39398@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

"AMD64 Fedora Rawhide Clang 3.x" buildbot worker is currently broken:
https://buildbot.python.org/all/#/builders/169/builds/168

clang cannot build (statically linked) binary using UBSan:

$ ./configure --prefix '$(PWD)/target' CC=clang LD=clang CFLAGS=-fsanitize=undefined LDFLAGS=-fsanitize=undefined
...
checking for gcc... clang
checking whether the C compiler works... no
configure: error: in `/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-x86_64.clang-ubsan/build':
configure: error: C compiler cannot create executables
See `config.log' for more details

I reproduced the issue on the worker. The issue comes from a version conflict between clang and compiler-rt packages:

compiler-rt-9.0.0-1.fc32.x86_64 uses /usr/lib64/clang/9.0.0/...

vs

clang-9.0.1-2.fc32.x86_64 uses /usr/lib64/clang/9.0.1/...

Charalampos created https://src.fedoraproject.org/rpms/compiler-rt/pull-request/10 to propose to update compiler-rt.

----------
components: Tests
keywords: buildbot
messages: 360324
nosy: vstinner
priority: normal
severity: normal
status: open
title: AMD64 Fedora Rawhide Clang 3.x: C compiler cannot create executables
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39398>
_______________________________________

From report at bugs.python.org  Mon Jan 20 12:18:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 20 Jan 2020 17:18:16 +0000
Subject: [issue37096] Add large-file tests for modules using sendfile(2)
In-Reply-To: <1559200699.13.0.758657145229.issue37096@roundup.psfhosted.org>
Message-ID: <1579540696.95.0.0685192328234.issue37096@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Right now, "AMD64 Fedora Rawhide Clang 3.x" worker is broken: "C compiler cannot create executables"
https://bugs.python.org/issue39398

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37096>
_______________________________________

From report at bugs.python.org  Mon Jan 20 12:29:47 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 20 Jan 2020 17:29:47 +0000
Subject: [issue39293] Windows 10 64-bit needs reboot after install
In-Reply-To: <1578690694.46.0.197073018811.issue39293@roundup.psfhosted.org>
Message-ID: <1579541387.19.0.483666694855.issue39293@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


Removed file: https://bugs.python.org/file48854/windows-ssh-tools.snapshot.json

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39293>
_______________________________________

From report at bugs.python.org  Mon Jan 20 13:02:13 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 20 Jan 2020 18:02:13 +0000
Subject: [issue39386] getting invalid data from async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1579543333.72.0.597011253134.issue39386@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks for the report.

Your example could be boiled down to the following:

coro = asynciter()
await coro
await coro

The second call incorrectly returns None but should raise an exception, double awaiting is a programming error.

For regular async functions it raises "RuntimeError: cannot reuse already awaited coroutine"

----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Mon Jan 20 13:03:03 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 20 Jan 2020 18:03:03 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1579543383.62.0.122713648785.issue39386@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
title: getting invalid data from async iterator -> Prevent double awaiting of async iterator
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Mon Jan 20 13:07:15 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 20 Jan 2020 18:07:15 +0000
Subject: [issue30951] Documentation error in inspect module
In-Reply-To: <1500312575.69.0.52467451771.issue30951@psf.upfronthosting.co.za>
Message-ID: <1579543635.78.0.233894036675.issue30951@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30951>
_______________________________________

From report at bugs.python.org  Mon Jan 20 13:08:04 2020
From: report at bugs.python.org (William Chargin)
Date: Mon, 20 Jan 2020 18:08:04 +0000
Subject: [issue18819] tarfile fills devmajor and devminor fields even for
 non-devices
In-Reply-To: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>
Message-ID: <1579543684.02.0.780275650876.issue18819@roundup.psfhosted.org>


Change by William Chargin <wchargin at gmail.com>:


----------
pull_requests: +17472
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18080

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18819>
_______________________________________

From report at bugs.python.org  Mon Jan 20 13:10:17 2020
From: report at bugs.python.org (William Chargin)
Date: Mon, 20 Jan 2020 18:10:17 +0000
Subject: [issue18819] tarfile fills devmajor and devminor fields even for
 non-devices
In-Reply-To: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>
Message-ID: <1579543817.67.0.333702888138.issue18819@roundup.psfhosted.org>


William Chargin <wchargin at gmail.com> added the comment:

I've just independently run into this and sent a patch as a pull
request. Happily, once this is fixed, the output of `tarfile` is
bit-for-bit compatible with the output of GNU `tar(1)`.

PR: <https://github.com/python/cpython/pull/18080>

----------
nosy: +wchargin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18819>
_______________________________________

From report at bugs.python.org  Mon Jan 20 13:10:25 2020
From: report at bugs.python.org (William Chargin)
Date: Mon, 20 Jan 2020 18:10:25 +0000
Subject: [issue18819] tarfile fills devmajor and devminor fields even for
 non-devices
In-Reply-To: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>
Message-ID: <1579543825.77.0.524118775461.issue18819@roundup.psfhosted.org>


Change by William Chargin <wchargin at gmail.com>:


----------
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/issue18819>
_______________________________________

From report at bugs.python.org  Mon Jan 20 14:21:14 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 20 Jan 2020 19:21:14 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579548074.44.0.292329240591.issue39396@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Mark: what's your call on that one?

I don't know. It's a hard problem in general: where do we draw the line between simply wrapping the platform libm, bugs and all, on one hand and trying to abstract away platform differences and make guarantees about corner-case behaviour on the other.

For this particular case, I'd be fine with adding a special case for `x == y` in the code (suitably commented to explain why the special case is there, and under what conditions it can be removed). But I fear it's the thin end of the wedge: as Michael's last message shows, to get the test suite to pass on his particular flavour of AIX, we'd need to add a special case for cmath.exp, too, and there may be more failures once that's fixed.

Actually, the cmath.exp failure looks a little odd to my eyes: it would be a bit surprising to have cmath.exp fail if all of test_math passed. I suspect a dodgy compiler optimisation. But that's another issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Mon Jan 20 14:29:10 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 20 Jan 2020 19:29:10 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579548550.62.0.329952414674.issue39396@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

BTW, stupid question: why is `test_nextafter` in `test.test_math.IsCloseTests` and `test.test_cmath.IsCloseTests`? The first seems inappropriate; the second even more so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Mon Jan 20 14:42:05 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 20 Jan 2020 19:42:05 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1579549325.42.0.169309718692.issue39386@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +17473
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18081

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Mon Jan 20 14:46:07 2020
From: report at bugs.python.org (Andrew Aladjev)
Date: Mon, 20 Jan 2020 19:46:07 +0000
Subject: [issue39399] Cross compilation using different libc is broken
Message-ID: <1579549567.58.0.700801348732.issue39399@roundup.psfhosted.org>


New submission from Andrew Aladjev <aladjev.andrew at gmail.com>:

Hello. I am implementing python cross compilation using "x86_64-pc-linux-musl" toolchain: "x86_64-pc-linux-musl-emerge -v1 python:3.6". Please see the following build log https://gist.github.com/andrew-aladev/e10fa5a8151ffb3c5782edd64ae08b28.

We can see the following part:

Traceback (most recent call last):
  File "/usr/x86_64-pc-linux-musl/tmp/portage/dev-lang/python-3.6.9/image//usr/lib/python3.6/compileall.py", line 17, in <module>
    import struct
  File "/usr/x86_64-pc-linux-musl/tmp/portage/dev-lang/python-3.6.9/image/usr/lib/python3.6/struct.py", line 13, in <module>
    from _struct import *
ImportError: libc.so: cannot open shared object file: No such file or directory

It means that cross compilation of python is not reliable today by design. Python is trying to use PYTHON_FOR_BUILD for loading cross compiled modules. It is not possible in general case. PYTHON_FOR_BUILD should not try to load cross compiled modules.

Please see the following gentoo issue https://bugs.gentoo.org/705970. I've attached a gentoo specific workaround there.

----------
components: Build
messages: 360330
nosy: puchenyaka
priority: normal
severity: normal
status: open
title: Cross compilation using different libc is broken
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39399>
_______________________________________

From report at bugs.python.org  Mon Jan 20 14:59:33 2020
From: report at bugs.python.org (Mark Sapiro)
Date: Mon, 20 Jan 2020 19:59:33 +0000
Subject: [issue39384] Email parser creates a message object that can't be
 flattened as bytes.
In-Reply-To: <1579376923.42.0.439623129413.issue39384@roundup.psfhosted.org>
Message-ID: <1579550373.31.0.760871929465.issue39384@roundup.psfhosted.org>


Mark Sapiro <mark at msapiro.net> added the comment:

This came about because of an actual situation in a Mailman 3 installation. I can't say for sure what the actual original message looked like, but it was received by Mailman's LMTP server and parsed with email.message_from_bytes(), so it clearly wasn't exactly like the message excerpt I posted in the report above. However, All I had to go by was the message object from the shunted pickle file created as a result of the exception.

The message was processed by Mailman, but when Mailman's handler pipeline attempted to save it for the digest, it calls an instance of mailbox.MMDF to add the message to the mailbox accumulating messages for the digest, and that in turn calls the flatten method of an email.generator.BytesGenerator instance. and that's where the exception was thrown.

Perhaps the suggested patch in https://github.com/python/cpython/pull/18056 doesn't address every possible case, and it can result in a slightly garbled message due to replacing 'invalid' characters, but in my case at least, it is much preferable to the alternative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39384>
_______________________________________

From report at bugs.python.org  Mon Jan 20 15:45:40 2020
From: report at bugs.python.org (Matt Kokotovich)
Date: Mon, 20 Jan 2020 20:45:40 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
In-Reply-To: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>
Message-ID: <1579553140.66.0.689918485583.issue39082@roundup.psfhosted.org>


Change by Matt Kokotovich <mkokotovich at gmail.com>:


----------
nosy: +mkokotovich

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Mon Jan 20 16:02:23 2020
From: report at bugs.python.org (Ronan Pigott)
Date: Mon, 20 Jan 2020 21:02:23 +0000
Subject: [issue39400] pydoc: Use of MANPAGER variable is incorrect
Message-ID: <1579554143.61.0.454786328579.issue39400@roundup.psfhosted.org>


New submission from Ronan Pigott <rpigott at berkeley.edu>:

pydoc references the value of both MANPAGER and PAGER variables when selecting a command to present the user with documentation. Those values are passed directly to subprocess.Popen. However, MANPAGER may contain arguments that need splitting, and is explicitly documented as such in the `man 1 man` manpage:

> If $MANPAGER or $PAGER is set ($MANPAGER is used in preference), its value is used as the name of the program used to display the manual page. [...] The value may be a simple command name or a command with arguments, and may  use  shell quoting (backslashes,  single quotes, or double quotes). It may not use pipes to connect multiple commands; if you need that, use a wrapper script [...]

pydoc should perform word splitting a la shlex.split on the values of MANPAGER and PAGER to retain compatibility with man.

----------
components: Library (Lib)
messages: 360332
nosy: Brocellous
priority: normal
severity: normal
status: open
title: pydoc: Use of MANPAGER variable is incorrect
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39400>
_______________________________________

From report at bugs.python.org  Mon Jan 20 16:05:29 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Jan 2020 21:05:29 +0000
Subject: [issue39379] sys.path[0] is already absolute path
In-Reply-To: <1579333617.11.0.372896670301.issue39379@roundup.psfhosted.org>
Message-ID: <1579554329.21.0.504431518051.issue39379@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Is sys.path[0] always absolute, or is it just a side-effect of the site module (i.e. is it absolute even with -S)?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39379>
_______________________________________

From report at bugs.python.org  Mon Jan 20 16:12:19 2020
From: report at bugs.python.org (Erik Aronesty)
Date: Mon, 20 Jan 2020 21:12:19 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1579554739.06.0.892165849584.issue35003@roundup.psfhosted.org>


Erik Aronesty <erik at q32.com> added the comment:

the single Scripts/activate tool should be simply copied to bin/activate ... this is what you have to do to write a bash script for python now:

source bin/activate || source Scripts/activate

we should not assume that all windows users use things like CMD and PowerShell, and instead just make support for "shell activation" be cross-platform

----------
nosy: +earonesty

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Mon Jan 20 16:49:43 2020
From: report at bugs.python.org (Ronan Pigott)
Date: Mon, 20 Jan 2020 21:49:43 +0000
Subject: [issue39400] pydoc: Use of MANPAGER variable is incorrect
In-Reply-To: <1579554143.61.0.454786328579.issue39400@roundup.psfhosted.org>
Message-ID: <1579556983.22.0.0663979896262.issue39400@roundup.psfhosted.org>


Ronan Pigott <rpigott at berkeley.edu> added the comment:

Actually my previous comment is incorrect, the value of the PAGER is split with the shell as a result of shell=True. There _is_ still an incompatibility with man.

I have a value for MANPAGER set like 'env LESS_TERMCAP_mb=^[[01;31m ... less' which becomes split on ';' by the shell as a result of 'shell=True'. The MANPAGER value is not interpreted by a shell with man, so it works as expected when using man.

Becuase man explicitly allows the use of quotes, it is possible to set a value of MANPAGER that has the desired effect for both programs by quoting the terminal control sequences like so: 'env LESS="^[[01;31m ... less"'.

Still, it might be reasonable to change pydocs interpretation of MANPAGER to better align with man's.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39400>
_______________________________________

From report at bugs.python.org  Mon Jan 20 16:57:47 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 20 Jan 2020 21:57:47 +0000
Subject: [issue39383] Mention Darwin as a potential value for platform.system()
In-Reply-To: <1579370263.63.0.178339292533.issue39383@roundup.psfhosted.org>
Message-ID: <1579557467.64.0.978008112067.issue39383@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39383>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:03:16 2020
From: report at bugs.python.org (Erik Aronesty)
Date: Mon, 20 Jan 2020 22:03:16 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1579557796.56.0.45361338809.issue35003@roundup.psfhosted.org>


Change by Erik Aronesty <erik at q32.com>:


----------
pull_requests: +17474
pull_request: https://github.com/python/cpython/pull/18083

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:04:21 2020
From: report at bugs.python.org (Erik Aronesty)
Date: Mon, 20 Jan 2020 22:04:21 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1579557861.71.0.499077826439.issue35003@roundup.psfhosted.org>


Erik Aronesty <erik at q32.com> added the comment:

See https://github.com/python/cpython/pull/18083 for an example of a 'simple copy' for shell script compatibility ... rather than trying to make Scripts move around (which it can't trivially).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:19:51 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 20 Jan 2020 22:19:51 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1579558791.12.0.24559463295.issue35134@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
pull_requests: +17475
pull_request: https://github.com/python/cpython/pull/18052

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:21:39 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 20 Jan 2020 22:21:39 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1579558899.41.0.914332742105.issue35134@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 1e420f849d0c094098543d2c27d35eaec69b2784 by Nick Coghlan in branch 'master':
bpo-35134: Migrate frameobject.h contents to cpython/frameobject.h (GH-18052)
https://github.com/python/cpython/commit/1e420f849d0c094098543d2c27d35eaec69b2784


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:41:28 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Jan 2020 22:41:28 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1579560088.12.0.933879351901.issue3770@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Matthew, this tracker issue has been closed for over 10 years; posting new questions or comments to such is unlikely to get a response (I just happened to see your comment in passing).  If you believe you have identified a new issue with current versions of Python, you should search for newer issues and, if appropriate, open a new one with a reference to this one.  However, before doing that, I would do a web search on "cannot import name 'SemLock'"; you should find a number of references to situations that seem similar to yours with the cause being the lack of a working sem_open implementation as noted in the ImportError message, a condition that might just be a system configuration issue on the build system.  Good luck!

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:43:52 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Jan 2020 22:43:52 +0000
Subject: [issue39392] Python Turtle is not filling alternate overlapping areas
 of a shape with same color
In-Reply-To: <1579497263.75.0.682788787706.issue39392@roundup.psfhosted.org>
Message-ID: <1579560232.42.0.143398953787.issue39392@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +gregorlingl, willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39392>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:45:54 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Jan 2020 22:45:54 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579560354.02.0.52698513701.issue39390@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
keywords: +3.8regression -patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:46:49 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Jan 2020 22:46:49 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579560409.59.0.961348955006.issue39390@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
keywords: +patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:48:02 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jan 2020 22:48:02 +0000
Subject: [issue39381] Fix get_event_loop documentation
In-Reply-To: <1579354241.45.0.104349162739.issue39381@roundup.psfhosted.org>
Message-ID: <1579560482.31.0.817016040314.issue39381@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17476
pull_request: https://github.com/python/cpython/pull/18084

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39381>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:48:37 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jan 2020 22:48:37 +0000
Subject: [issue39381] Fix get_event_loop documentation
In-Reply-To: <1579354241.45.0.104349162739.issue39381@roundup.psfhosted.org>
Message-ID: <1579560517.25.0.52593543069.issue39381@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17477
pull_request: https://github.com/python/cpython/pull/18085

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39381>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:49:37 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 20 Jan 2020 22:49:37 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1579560577.41.0.843509877048.issue39386@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset a96e06db77dcbd3433d39761ddb4615d7d96284a by Andrew Svetlov in branch 'master':
bpo-39386: Prevent double awaiting of async iterator (GH-18081)
https://github.com/python/cpython/commit/a96e06db77dcbd3433d39761ddb4615d7d96284a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:49:53 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jan 2020 22:49:53 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1579560593.37.0.101897141001.issue39386@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17479
pull_request: https://github.com/python/cpython/pull/18087

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:49:46 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jan 2020 22:49:46 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1579560586.33.0.986941812951.issue39386@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17478
pull_request: https://github.com/python/cpython/pull/18086

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Mon Jan 20 17:52:57 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 20 Jan 2020 22:52:57 +0000
Subject: [issue39381] Fix get_event_loop documentation
In-Reply-To: <1579354241.45.0.104349162739.issue39381@roundup.psfhosted.org>
Message-ID: <1579560777.55.0.448958707423.issue39381@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39381>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:05:00 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Jan 2020 23:05:00 +0000
Subject: [issue18819] tarfile fills devmajor and devminor fields even for
 non-devices
In-Reply-To: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>
Message-ID: <1579561500.28.0.548809940213.issue18819@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ethan.furman
versions:  -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18819>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:06:44 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jan 2020 23:06:44 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1579561604.23.0.876396942834.issue39386@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5cadd3fe3aead1b5bee1438dc03383d6739d4209 by Miss Islington (bot) in branch '3.8':
bpo-39386: Prevent double awaiting of async iterator (GH-18081)
https://github.com/python/cpython/commit/5cadd3fe3aead1b5bee1438dc03383d6739d4209


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:07:58 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jan 2020 23:07:58 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1579561678.14.0.91195306092.issue39386@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b76d5e9ee64b8ac861e856d8e41289c0977c75e1 by Miss Islington (bot) in branch '3.7':
bpo-39386: Prevent double awaiting of async iterator (GH-18081)
https://github.com/python/cpython/commit/b76d5e9ee64b8ac861e856d8e41289c0977c75e1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:13:41 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Jan 2020 23:13:41 +0000
Subject: [issue39399] Cross compilation using different libc is broken
In-Reply-To: <1579549567.58.0.700801348732.issue39399@roundup.psfhosted.org>
Message-ID: <1579562021.51.0.859674437393.issue39399@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report. This appears to be a duplicate of languishing Issue22724.  Suggest you join the discussion there.

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> byte-compile fails for cross-builds

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39399>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:23:00 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Jan 2020 23:23:00 +0000
Subject: [issue39383] Mention Darwin as a potential value for platform.system()
In-Reply-To: <1579370263.63.0.178339292533.issue39383@roundup.psfhosted.org>
Message-ID: <1579562580.17.0.898819826758.issue39383@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 8d57a4182f0aa68e16d66dea31ba59e732612b4f by Ned Deily (Peter Bittner) in branch 'master':
bpo-39383: Mention Darwin as a potential value for platform.system() (GH-18054)
https://github.com/python/cpython/commit/8d57a4182f0aa68e16d66dea31ba59e732612b4f


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39383>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:23:10 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jan 2020 23:23:10 +0000
Subject: [issue39383] Mention Darwin as a potential value for platform.system()
In-Reply-To: <1579370263.63.0.178339292533.issue39383@roundup.psfhosted.org>
Message-ID: <1579562590.25.0.387535759858.issue39383@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +17480
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18088

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39383>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:23:16 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jan 2020 23:23:16 +0000
Subject: [issue39383] Mention Darwin as a potential value for platform.system()
In-Reply-To: <1579370263.63.0.178339292533.issue39383@roundup.psfhosted.org>
Message-ID: <1579562596.91.0.0953618421117.issue39383@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17481
pull_request: https://github.com/python/cpython/pull/18089

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39383>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:28:22 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jan 2020 23:28:22 +0000
Subject: [issue39383] Mention Darwin as a potential value for platform.system()
In-Reply-To: <1579370263.63.0.178339292533.issue39383@roundup.psfhosted.org>
Message-ID: <1579562902.18.0.487490648203.issue39383@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3da839046359644f286195f5126035e162440af1 by Miss Islington (bot) in branch '3.7':
bpo-39383: Mention Darwin as a potential value for platform.system() (GH-18054)
https://github.com/python/cpython/commit/3da839046359644f286195f5126035e162440af1


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39383>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:28:47 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 20 Jan 2020 23:28:47 +0000
Subject: [issue39383] Mention Darwin as a potential value for platform.system()
In-Reply-To: <1579370263.63.0.178339292533.issue39383@roundup.psfhosted.org>
Message-ID: <1579562927.62.0.969770959519.issue39383@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c1964e09421e7ab61179eb4e2691e858a50d70e5 by Miss Islington (bot) in branch '3.8':
bpo-39383: Mention Darwin as a potential value for platform.system() (GH-18054)
https://github.com/python/cpython/commit/c1964e09421e7ab61179eb4e2691e858a50d70e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39383>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:38:36 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 20 Jan 2020 23:38:36 +0000
Subject: [issue39383] Mention Darwin as a potential value for platform.system()
In-Reply-To: <1579370263.63.0.178339292533.issue39383@roundup.psfhosted.org>
Message-ID: <1579563516.45.0.75127892515.issue39383@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the PR!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: enhancement -> 
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39383>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:42:05 2020
From: report at bugs.python.org (William Woodruff)
Date: Mon, 20 Jan 2020 23:42:05 +0000
Subject: [issue29435] Allow to pass fileobj to is_tarfile
In-Reply-To: <1486132653.21.0.166387912558.issue29435@psf.upfronthosting.co.za>
Message-ID: <1579563725.79.0.813726021587.issue29435@roundup.psfhosted.org>


Change by William Woodruff <william at yossarian.net>:


----------
keywords: +patch
pull_requests: +17482
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18090

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29435>
_______________________________________

From report at bugs.python.org  Mon Jan 20 18:45:40 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 20 Jan 2020 23:45:40 +0000
Subject: [issue39386] Prevent double awaiting of async iterator
In-Reply-To: <1579416220.77.0.52401810488.issue39386@roundup.psfhosted.org>
Message-ID: <1579563940.22.0.434137566219.issue39386@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39386>
_______________________________________

From report at bugs.python.org  Mon Jan 20 20:02:15 2020
From: report at bugs.python.org (Anthony Wee)
Date: Tue, 21 Jan 2020 01:02:15 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
Message-ID: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>


New submission from Anthony Wee <antxwee at gmail.com>:

On Win7, running Python in the terminal will attempt to load the "api-ms-win-core-path-l1-1-0.dll" from various paths outside of the Python directory and the C:\Windows\System32 directories. This behavior can be verified using Process Monitor (see attachment).

This is happening due to direct calls to LoadLibraryW() in getpathp.c without any "LOAD_LIBRARY_SEARCH*" flags.

In join():

https://github.com/python/cpython/blob/c02b41b1fb115c87693530ea6a480b2e15460424/PC/getpathp.c#L255

and canonicalize():

https://github.com/python/cpython/blob/c02b41b1fb115c87693530ea6a480b2e15460424/PC/getpathp.c#L291

For both cases, the methods they are trying to load from api-ms-win-core-path-l1-1-0.dll (PathCchCanonicalizeEx and PathCchCombineEx) were introduced in Win8. 

I tested on Win7 and Win10 and they differ in how they load these api-ms-win-* dll's and whether they appear in process monitor. In Win7, a CreateFile event appears in procmon, while in Win10 it seems like the OS is automatically loading the module from kernelbase.dll. Also in Win7 the loading of api-ms-win-core-path-l1-1-0.dll will fail while in Win10 it succeeds. However, in Win7 when it fails it results in the standard dll search strategy, which will eventually search outside of the secure directories such as the directories in the PATH env var: https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

Each of the problematic methods in cpython have a pattern of attempting to load the dll, then falling back to an older version of the method. Thus in Win7, the dll fails to load and it falls back to the older version of the method. In Win10, the dll load succeeds and we use the new versions of the methods.

I'm working on a fix to pass the LOAD_LIBRARY_SEARCH_DEFAULT_DIRS flag to limit to the dll search path scope.

----------
files: python unsafe dll loading.png
messages: 360348
nosy: anthonywee
priority: normal
severity: normal
status: open
title: Unsafe dll loading in getpathp.c on Win7
Added file: https://bugs.python.org/file48855/python unsafe dll loading.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Mon Jan 20 21:57:42 2020
From: report at bugs.python.org (Raymond Leiter)
Date: Tue, 21 Jan 2020 02:57:42 +0000
Subject: [issue39402] Consistent use of terms
Message-ID: <1579575462.08.0.745933853116.issue39402@roundup.psfhosted.org>


New submission from Raymond Leiter <rayrleiter at gmail.com>:

This is my idea of an improvement to the documentation, but I doubt anyone would agree with me.
Nevertheless, here it is:
There are at least 4 commonly used characters used to group other constructs to clearly call attention to their meaning.
1. [] Brackets
2. {} Braces
3. () Parentheses
4. <> Less than/Greater than 

The problem I have with the way these symbols are spoken of (in writing as well as oral discourse) is the lack of consistent names for them.
Brackets are often referred to as square Brackets, even though there is apparently no alternative such as rectangular Brackets, etc.
Braces are often referred to as curly Braces or some times curly Brackets.
Parentheses are usually called, correctly, Parentheses, but also referred to as round Brackets. I've never encountered 'round Braces', but I'm hopeful.
Less then and Greater then symbols are referred to correctly when they are used in mathematics speak.
However, when they are used as a 'grouping' mechanism, they are usually called Angle Brackets -- not Angle Braces.
My proposal is this:
The most consistent way I can think of for referring to these 4 symbols when used as a 'grouping' mechanism is:
1. [] SQUARE BRACKETS
2. {} CURLY BRACKETS
3. () ROUND BRACKETS
4. <> ANGLE BRACKETS
There will be no more Braces, since that term is apparently quite unpopular with most programmers today.
The 'shape' modifiers (SQUARE, CURLY, ROUND, ANGLE), applied to the 
common term BRACKETS, would appear to be much more consistent than current usage.
I'm well aware of the difficulty in garnering support for this kind of an 'improvement', but I felt it needed said.

----------
assignee: docs at python
components: Documentation
messages: 360349
nosy: Raymond Leiter, docs at python
priority: normal
severity: normal
status: open
title: Consistent use of terms
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39402>
_______________________________________

From report at bugs.python.org  Mon Jan 20 23:34:55 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 21 Jan 2020 04:34:55 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1579581295.28.0.85632687487.issue39401@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> On Win7, running Python in the terminal will attempt to load the 
> "api-ms-win-core-path-l1-1-0.dll" from various paths outside of the 
> Python directory and the C:\Windows\System32 directories.

"api-ms-win-core-path-l1-1-0.dll" is not assigned in the API set schema (in ApiSetSchema.dll) in Windows 7. Since the name is neither in the list of known DLLs nor the list of assigned API sets, the loader searches for it in the normal way. (FYI, the number of API sets increased from 35 in Windows 7 up to 502 in Windows 8.1.)

> I'm working on a fix to pass the LOAD_LIBRARY_SEARCH_DEFAULT_DIRS

I think this could use just LOAD_LIBRARY_SEARCH_SYSTEM32. I see no reason to try to load "api-ms-win-core-path-l1-1-0.dll" from the application directory or user directories.

I'm adding 3.6-3.9 to the list of affected versions. In 3.9 it can use a static import instead (i.e. remove LoadLibraryaExW / GetProcAddress), since only Windows 8.1+ is supported.

----------
components: +Windows
nosy: +eryksun, paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> needs patch
type:  -> security
versions: +Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Mon Jan 20 23:51:26 2020
From: report at bugs.python.org (wh1te r4bb1t)
Date: Tue, 21 Jan 2020 04:51:26 +0000
Subject: [issue39403] Objects equal (assertEqual return True) but behave
 differently
Message-ID: <1579582286.19.0.437122488407.issue39403@roundup.psfhosted.org>


New submission from wh1te r4bb1t <wh1te.r4bb1t at protonmail.com>:

Here is a code highlighting a very strange behavior. This has been noticed in  python 3.7, 3.8 and 3.9.0a2


def function(input_list, a='x'):
    [input_list[i].append(a) for i in range(len(input_list))]
    return input_list

list1 = [[0], [0], [0]]
list2 = [[0]] * 3

list1 == list2   # return True

function(list1)  # return [[0, 'x'], [0, 'x'], [0, 'x']]
function(list2)  # return [[0, 'x', 'x', 'x'], [0, 'x', 'x', 'x'], [0, 'x', 'x', 'x']]

list1 == list2   # return false

----------
messages: 360351
nosy: wh1te r4bb1t
priority: normal
severity: normal
status: open
title: Objects equal (assertEqual return True) but behave differently
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39403>
_______________________________________

From report at bugs.python.org  Mon Jan 20 23:51:43 2020
From: report at bugs.python.org (wh1te r4bb1t)
Date: Tue, 21 Jan 2020 04:51:43 +0000
Subject: [issue39403] Objects equal (assertEqual return True) but behave
 differently
In-Reply-To: <1579582286.19.0.437122488407.issue39403@roundup.psfhosted.org>
Message-ID: <1579582303.7.0.52999477648.issue39403@roundup.psfhosted.org>


Change by wh1te r4bb1t <wh1te.r4bb1t at protonmail.com>:


----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39403>
_______________________________________

From report at bugs.python.org  Mon Jan 20 23:52:38 2020
From: report at bugs.python.org (wh1te r4bb1t)
Date: Tue, 21 Jan 2020 04:52:38 +0000
Subject: [issue39403] Objects equal (assertEqual return True) but behave
 differently
In-Reply-To: <1579582286.19.0.437122488407.issue39403@roundup.psfhosted.org>
Message-ID: <1579582358.44.0.537296616756.issue39403@roundup.psfhosted.org>


Change by wh1te r4bb1t <wh1te.r4bb1t at protonmail.com>:


----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39403>
_______________________________________

From report at bugs.python.org  Mon Jan 20 23:56:04 2020
From: report at bugs.python.org (David Barnett)
Date: Tue, 21 Jan 2020 04:56:04 +0000
Subject: [issue32308] Replace empty matches adjacent to a previous non-empty
 match in re.sub()
In-Reply-To: <1513189718.03.0.213398074469.issue32308@psf.upfronthosting.co.za>
Message-ID: <1579582564.32.0.169044453336.issue32308@roundup.psfhosted.org>


David Barnett <davidbarnett2 at gmail.com> added the comment:

We were also bitten by this behavior change in https://github.com/google/vroom/issues/110. I'm kinda baffled by the new behavior and assumed it had to be an accidental regression, but I guess not. If you have any other context on the BDFL conversation and reasoning for calling this behavior correct, I'd love to see additional info.

----------
nosy: +mu_mind

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32308>
_______________________________________

From report at bugs.python.org  Tue Jan 21 00:13:24 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 21 Jan 2020 05:13:24 +0000
Subject: [issue39403] Objects equal (assertEqual return True) but behave
 differently
In-Reply-To: <1579582286.19.0.437122488407.issue39403@roundup.psfhosted.org>
Message-ID: <1579583604.63.0.0418119325331.issue39403@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

For `list1`, you are creating three separate lists containing `0` contained by a fourth list.  For `list2`, you're creating a single list containing `0` contained by a second list, and then replicating the contents of that second list three times; thus `list2` actually contains the same list object three times.  You can compare the result of `[id(l) for l in list1]` with the same for `list2` to see this.

See point 2 here [1] and in this [2] FAQ for more information on this.

[1] https://docs.python.org/3/library/stdtypes.html#common-sequence-operations
[2] https://docs.python.org/3/faq/programming.html#faq-multidimensional-list

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39403>
_______________________________________

From report at bugs.python.org  Tue Jan 21 01:01:09 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 21 Jan 2020 06:01:09 +0000
Subject: [issue39397] Mac : fail to launch Python 3.8
In-Reply-To: <1579535856.72.0.329847745345.issue39397@roundup.psfhosted.org>
Message-ID: <1579586469.87.0.0937793634115.issue39397@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Try `locale` command.  What is shown?

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39397>
_______________________________________

From report at bugs.python.org  Tue Jan 21 01:07:35 2020
From: report at bugs.python.org (=?utf-8?q?Anders_Hovm=C3=B6ller?=)
Date: Tue, 21 Jan 2020 06:07:35 +0000
Subject: [issue32308] Replace empty matches adjacent to a previous non-empty
 match in re.sub()
In-Reply-To: <1579582564.32.0.169044453336.issue32308@roundup.psfhosted.org>
Message-ID: <7252A3D5-E110-44EC-91EC-FD15F3CF81E3@killingar.net>


Anders Hovm?ller <boxed at killingar.net> added the comment:

We were also bitten by this. In fact we still run a compatibility shim in production where we log if the new and old behavior are different. We also didn't think this "bug fix" made sense or was treated with the appropriate gravity in the release notes. 

I understand the logic in the bug tracker and they it matches other languages is good. But the bahvior also makes no sense for the .* case unfortunately. 

> On 21 Jan 2020, at 05:56, David Barnett <report at bugs.python.org> wrote:
> 
> ?
> David Barnett <davidbarnett2 at gmail.com> added the comment:
> 
> We were also bitten by this behavior change in https://github.com/google/vroom/issues/110. I'm kinda baffled by the new behavior and assumed it had to be an accidental regression, but I guess not. If you have any other context on the BDFL conversation and reasoning for calling this behavior correct, I'd love to see additional info.
> 
> ----------
> nosy: +mu_mind
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue32308>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32308>
_______________________________________

From report at bugs.python.org  Tue Jan 21 01:44:42 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 21 Jan 2020 06:44:42 +0000
Subject: [issue39393] Misleading error message upon dependent DLL resolution
 failure
In-Reply-To: <1579512450.11.0.864670825995.issue39393@roundup.psfhosted.org>
Message-ID: <1579589082.02.0.388698111408.issue39393@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +17483
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18093

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39393>
_______________________________________

From report at bugs.python.org  Tue Jan 21 02:01:51 2020
From: report at bugs.python.org (Archana Pandey)
Date: Tue, 21 Jan 2020 07:01:51 +0000
Subject: [issue39404] Pexpect : setwinsize() not working in SLES 12.4 kernel
 4.12.14-94.41-default
Message-ID: <1579590111.47.0.0702544598598.issue39404@roundup.psfhosted.org>


New submission from Archana Pandey <archi.pandey9190 at gmail.com>:

use of setwinsize function returns empty if the values of rows and cols differes from(24,80).
Issue occurs only on SLES 12.4.

sample code:
#!/usr/bin/env python
from pexpect import pxssh
try:
    s = pxssh.pxssh()
    hostname = 'someIp'
    username = 'username'
    password = 'password'
    s.login(hostname, username, password)
    s.setwinsize(1000,1000)  # setting default winsize works
    s.sendline('uname -r')   # run a command
    s.prompt()             # match the prompt
    print(s.before)        # print everything before the prompt.
    s.logout()
except pxssh.ExceptionPxssh as e:
    print("pxssh failed on login.")
    print(e)

----------
components: Library (Lib)
messages: 360356
nosy: archi-pandey
priority: normal
severity: normal
status: open
title: Pexpect : setwinsize() not working in SLES 12.4 kernel 4.12.14-94.41-default
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39404>
_______________________________________

From report at bugs.python.org  Tue Jan 21 02:19:49 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 21 Jan 2020 07:19:49 +0000
Subject: [issue39402] Consistent use of terms
In-Reply-To: <1579575462.08.0.745933853116.issue39402@roundup.psfhosted.org>
Message-ID: <1579591189.8.0.172130610476.issue39402@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't think we would ever consider replacing "parentheses" with "round brackets".  Also, we have long talked about "curly braces" though the braces/brackets choice is a little loose.  Also note that greater-than or less-than have established usage (see the html entities or unicode code point name for example).

> I'm well aware of the difficulty in garnering support for 
> this kind of an 'improvement', but I felt it needed said.

I appreciate that.  Thanks for the suggestion, but we'll decline a wholesale search and replace mission.  If an individual case of known confusion arises, we can take a look at it, but for now we have no evidence that the current docs are causing confusion for end users.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39402>
_______________________________________

From report at bugs.python.org  Tue Jan 21 02:46:19 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 21 Jan 2020 07:46:19 +0000
Subject: [issue39404] Pexpect : setwinsize() not working in SLES 12.4 kernel
 4.12.14-94.41-default
In-Reply-To: <1579590111.47.0.0702544598598.issue39404@roundup.psfhosted.org>
Message-ID: <1579592779.3.0.274960887737.issue39404@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The tracker is for issues related to CPython. Can you please add a reproducer without pexpect or other dependencies explaining the issue with Python? https://github.com/pexpect/pexpect/issues is the issue tracker for pexpect.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39404>
_______________________________________

From report at bugs.python.org  Tue Jan 21 02:50:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 07:50:37 +0000
Subject: [issue39397] Mac : fail to launch Python 3.8
In-Reply-To: <1579535856.72.0.329847745345.issue39397@roundup.psfhosted.org>
Message-ID: <1579593037.32.0.259843595789.issue39397@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Can you try to dump your environment variables? Try maybe the "env" command.

At least, I would need: LC_ALL, LC_CTYPE and LANG.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39397>
_______________________________________

From report at bugs.python.org  Tue Jan 21 02:52:12 2020
From: report at bugs.python.org (Sankar)
Date: Tue, 21 Jan 2020 07:52:12 +0000
Subject: [issue39405] Using relative path as a --prefix during configure.
Message-ID: <1579593132.28.0.601505757933.issue39405@roundup.psfhosted.org>


New submission from Sankar <sankar.kandasamy at agiloft.com>:

Is it possible to provide the relative path as a --prefix during configure?

I want to compile a python as a distributive package, so using an absolute path won't help. It should have a relative path like "../../Python".

The compiled python needs to have a relative everywhere, is it possible to achieve this?

----------
components: Build
messages: 360360
nosy: Sankark
priority: normal
severity: normal
status: open
title: Using relative path as a --prefix during configure.
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39405>
_______________________________________

From report at bugs.python.org  Tue Jan 21 02:53:21 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jan 2020 07:53:21 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579593200.99.0.970582410825.issue32989@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

After updating the patch, I noticed that deletion of self.context_use_ps1 from the editor call to y.find_good_parse_start was no longer part of the diff.  This is because 3.8 changeset 6bdc4dee01788599808c7858e2fe9fdd72cf6792 for #35610 (backported only to 3.7) already did so. The remaining substantive change other than new tests is the removal of the unused default value None in the signature of the function and unused code triggered by 'if not arg'. 

I don't remember how well I tested that never exiting find...start early left indentations unchanged.  This would require comparing behavior to 3.6.  It would make more sense to check that the behavior and new tests conform to PEP8.

----------
title: IDLE: Fix pyparse.find_good_parse_start and its bad editor call -> IDLE: Fix pyparse.find_good_parse_start

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Tue Jan 21 02:53:24 2020
From: report at bugs.python.org (Sankar)
Date: Tue, 21 Jan 2020 07:53:24 +0000
Subject: [issue39405] Using relative path as a --prefix during configure.
In-Reply-To: <1579593132.28.0.601505757933.issue39405@roundup.psfhosted.org>
Message-ID: <1579593204.06.0.773063772383.issue39405@roundup.psfhosted.org>


Change by Sankar <sankar.kandasamy at agiloft.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39405>
_______________________________________

From report at bugs.python.org  Tue Jan 21 03:01:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 08:01:55 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579593715.92.0.560070826272.issue39396@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17484
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18094

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Tue Jan 21 03:11:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 08:11:23 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579594283.01.0.297380423805.issue39396@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> For this particular case, I'd be fine with adding a special case for `x == y` in the code (suitably commented to explain why the special case is there, and under what conditions it can be removed).

I proposed PR 18094.

Because of your parenthesis, I chose to use "#if defined(_AIX)" with an an explicit comment on AIX version. For example, we may drop this workaround once we would like to drop support for AIX 7.1.


> Actually, the cmath.exp failure looks a little odd to my eyes: it would be a bit surprising to have cmath.exp fail if all of test_math passed. I suspect a dodgy compiler optimisation. But that's another issue.

Michael: would you mind to open a separated issue for "FAIL: test_specific_values (test.test_cmath.CMathTests)"? Is it on a buildbot? Please try to get the machine code of cmath_exp_impl() function. Example:

   objdump -d build/lib.linux-x86_64-3.9-pydebug/cmath.cpython-39d-x86_64-linux-gnu.so

or try gdb:
---
$ gdb ./python
GNU gdb (GDB) Fedora 8.3.50.20190824-26.fc31
(gdb) run
>>> import cmath

<press CTRL+C>

Program received signal SIGINT, Interrupt.
(gdb) set pagination off
(gdb) disassemble cmath_exp_impl 
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Tue Jan 21 03:23:07 2020
From: report at bugs.python.org (Andrew Aladjev)
Date: Tue, 21 Jan 2020 08:23:07 +0000
Subject: [issue39399] Cross compilation using different libc is broken
In-Reply-To: <1579549567.58.0.700801348732.issue39399@roundup.psfhosted.org>
Message-ID: <1579594987.07.0.0958753559705.issue39399@roundup.psfhosted.org>


Andrew Aladjev <aladjev.andrew at gmail.com> added the comment:

Hello, it seems like issue 22724 is completely the same. Let's discuss solutions there. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39399>
_______________________________________

From report at bugs.python.org  Tue Jan 21 03:23:33 2020
From: report at bugs.python.org (Andrew Aladjev)
Date: Tue, 21 Jan 2020 08:23:33 +0000
Subject: [issue22724] byte-compile fails for cross-builds
In-Reply-To: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za>
Message-ID: <1579595013.77.0.986557242167.issue22724@roundup.psfhosted.org>


Change by Andrew Aladjev <aladjev.andrew at gmail.com>:


----------
nosy: +puchenyaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22724>
_______________________________________

From report at bugs.python.org  Tue Jan 21 03:29:04 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 21 Jan 2020 08:29:04 +0000
Subject: [issue39397] Mac : fail to launch Python 3.8
In-Reply-To: <1579535856.72.0.329847745345.issue39397@roundup.psfhosted.org>
Message-ID: <1579595344.76.0.881288913953.issue39397@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

An additional question: what version of macOS are you using?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39397>
_______________________________________

From report at bugs.python.org  Tue Jan 21 03:30:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 08:30:02 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
Message-ID: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Currently, os.putenv() is always implemented with putenv(). The problem is that putenv(str) puts directly the string into the environment, the string is not copied. So Python has to keep track of this memory.

In Python 3.9, this string is now cleared at Python exit, without unsetting the environment variable which cause bpo-39395 crash.

I propose to implement os.putenv() with setenv() if available, which avoids bpo-39395 on platforms providing setenv().

----------
components: Library (Lib)
messages: 360365
nosy: vstinner
priority: normal
severity: normal
status: open
title: Implement os.putenv() with setenv() if available
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 03:36:37 2020
From: report at bugs.python.org (Andrew Aladjev)
Date: Tue, 21 Jan 2020 08:36:37 +0000
Subject: [issue22724] byte-compile fails for cross-builds
In-Reply-To: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za>
Message-ID: <1579595797.28.0.175681293043.issue22724@roundup.psfhosted.org>


Andrew Aladjev <aladjev.andrew at gmail.com> added the comment:

Hello. I've provided a double recompilation workaround in the following gentoo bug https://bugs.gentoo.org/705970. You can use it for now if you don't want to wait until this issue will be fixed.

I will try patches provided by people in this issue today's evening. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22724>
_______________________________________

From report at bugs.python.org  Tue Jan 21 03:53:51 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 21 Jan 2020 08:53:51 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1579596831.88.0.57577042915.issue35003@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The Scripts/bin thing is not specific to venv - for whatever reason, the original Windows implementation chose to use "Scripts" rather than "bin" for the executables directory under Windows, and I don't think it can be changed now without affecting backward compatibility. The venv code just fits into the existing, wider theme. My guess is you would need to propose a PEP to move *everything* over from "Scripts" to "bin" in the Windows Python world, and show that it would not break any existing code anywhere - seems like a tall order.

This issue was already rejected before you added your PR so I'm not sure why you went to the trouble of creating a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Tue Jan 21 03:53:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 08:53:51 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579596831.97.0.778455396118.issue39395@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fedora downstream issue, crash in the "elements" package: https://bugzilla.redhat.com/show_bug.cgi?id=1791761

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Tue Jan 21 03:56:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 08:56:59 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579597019.78.0.0397163981852.issue39406@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17485
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18095

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 03:57:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 08:57:41 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579597061.84.0.318973011885.issue39395@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I proposed bpo-39406 which avoids to have to clear environment variables set by Python at exit on platforms providing setenv().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Tue Jan 21 04:02:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 09:02:01 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579597321.02.0.501281112231.issue39406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

setenv() is available on:

* Linux: http://man7.org/linux/man-pages/man3/setenv.3.html
* macOS: https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/setenv.3.html
* FreeBSD: https://www.freebsd.org/cgi/man.cgi?query=getenv&sektion=3&apropos=0&manpath=FreeBSD+12.1-RELEASE

It is not available on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 04:12:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2020 09:12:23 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579597943.49.0.582964027053.issue39406@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Maybe use SetEnvironmentVariable() on Windows?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 04:20:46 2020
From: report at bugs.python.org (James)
Date: Tue, 21 Jan 2020 09:20:46 +0000
Subject: [issue39407] Bitfield Union does not work for bit widths greater than
 8 bits
Message-ID: <1579598446.4.0.992885601922.issue39407@roundup.psfhosted.org>


New submission from James <j.schulte01 at gmail.com>:

Creating a Bitfield from a ctypes union and structure results in unexpected behaviour. It seems when you set the bit-width of a structure field to be greater than 8 bits it results in the subsequent bits being set to zero.



class BitFieldStruct(ctypes.LittleEndianStructure):
    _fields_ = [
        ("long_field", C_UINT32, 29),
        ("short_field_0", C_UINT8, 1),
        ("short_field_1", C_UINT8, 1),
        ("short_field_2", C_UINT8, 1),
    ]


class BitField(ctypes.Union):
    _anonymous_ = ("fields",)
    _fields_ = [
        ("fields", BitFieldStruct),
        ("as32bit", C_UINT32)
    ]

def test_bit_field_union():
    f = BitField()
    f.as32bit = int.from_bytes([255, 255, 255, 255], byteorder='little')

    assert f.long_field == int.from_bytes([255, 255, 255, 31], byteorder='little')
    assert f.short_field_0 == 1
    assert f.short_field_1 == 1
    assert f.short_field_2 == 1

test_bit_field_union()  # this call will fail with an assertion error


Equivalent C which does not fail https://rextester.com/FWV78514

I'm running on Ubuntu 16.04 with python3.6 but I have tested on 3.5, 3.7 and on repl.it with the same behaviour.

It seems as though setting any of the struct fields to be greater than 8 bit width results in any of the following fields being set to zero.

----------
components: ctypes
files: python_struct_union_bug.py
messages: 360372
nosy: jschulte
priority: normal
severity: normal
status: open
title: Bitfield Union does not work for bit widths greater than 8 bits
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48856/python_struct_union_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39407>
_______________________________________

From report at bugs.python.org  Tue Jan 21 04:32:50 2020
From: report at bugs.python.org (Sebastian Noack)
Date: Tue, 21 Jan 2020 09:32:50 +0000
Subject: [issue39408] Add support for SQLCipher
Message-ID: <1579599170.77.0.875579101001.issue39408@roundup.psfhosted.org>


New submission from Sebastian Noack <sebastian.noack at gmail.com>:

SQLCipher is industry-standard technology for managing an encrypting SQLite databases. It has been implemented as a fork of SQLite3. So the sqlite3 corelib module would build as-is against it. But rather than a fork (of this module), I'd rather see integration of SQLCiper in upstream Python. I'm happy to volunteer if this changes have any chance of landing.

By just adding 2 lines to the cpython repository (and changing ~10 lines), I could make SQLCipher (based on the current sqlite3 module) available as a separate module (e.g. sqlcipher or sqlite3.cipher). However, IMO the ideal interface would be sqlilte3.connect(..., sqlcipher=True).

Any thoughts?

----------
messages: 360373
nosy: Sebastian.Noack
priority: normal
severity: normal
status: open
title: Add support for SQLCipher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39408>
_______________________________________

From report at bugs.python.org  Tue Jan 21 04:46:24 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 21 Jan 2020 09:46:24 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579599984.78.0.905687277789.issue39396@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So on cmath.exp, we've seen something like this before, on macOS. What was happening was that the C source contained matching `sin` and `cos` calls, and a compiler optimization replaced that pair of calls with a single call to C's cexp. And then cexp didn't handle the zero signs correctly.

I don't have an issue reference to hand; all this is from (highly fallible) memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Tue Jan 21 04:48:59 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 21 Jan 2020 09:48:59 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579600139.18.0.639535065074.issue39396@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I don't have an issue reference to hand

See #18513.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Tue Jan 21 04:55:51 2020
From: report at bugs.python.org (Sebastien Foo)
Date: Tue, 21 Jan 2020 09:55:51 +0000
Subject: [issue39397] Mac : fail to launch Python 3.8
In-Reply-To: <1579535856.72.0.329847745345.issue39397@roundup.psfhosted.org>
Message-ID: <1579600551.35.0.399400176726.issue39397@roundup.psfhosted.org>


Sebastien Foo <sgandon at gmail.com> added the comment:

thanks averyone to help me
here are the values you are expecting

locale
LANG="en_US"
LC_COLLATE="en_US"
LC_CTYPE="en_US"
LC_MESSAGES="en_US"
LC_MONETARY="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_ALL=

doing env I get this (no LC_ALL )
LC_TERMINAL_VERSION=3.3.7
ITERM_PROFILE=zsh
XPC_FLAGS=0x0
LANG=en_US
SHELL=/usr/local/bin/zsh
TERM_PROGRAM_VERSION=3.3.7
TERM_PROGRAM=iTerm.app
LC_TERMINAL=iTerm2
LC_CTYPE=en_US

And for the last question I am using Catalina 10.15.2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39397>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:00:05 2020
From: report at bugs.python.org (Archana Pandey)
Date: Tue, 21 Jan 2020 10:00:05 +0000
Subject: [issue39404] Pexpect : setwinsize() not working in SLES 12.4 kernel
 4.12.14-94.41-default
In-Reply-To: <1579590111.47.0.0702544598598.issue39404@roundup.psfhosted.org>
Message-ID: <1579600805.33.0.920816209953.issue39404@roundup.psfhosted.org>


Change by Archana Pandey <archi.pandey9190 at gmail.com>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39404>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:00:06 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 21 Jan 2020 10:00:06 +0000
Subject: [issue39397] Mac : fail to launch Python 3.8
In-Reply-To: <1579535856.72.0.329847745345.issue39397@roundup.psfhosted.org>
Message-ID: <1579600806.22.0.772266226105.issue39397@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> doing env I get this (no LC_ALL )
[snip]
> LC_CTYPE=en_US

This is wrong setting.  Find where this environment variable is set and remove it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39397>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:03:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 10:03:49 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579601029.16.0.918309892553.issue39406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Maybe use SetEnvironmentVariable() on Windows?

I didn't know this function. I updated PR 18095.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:10:44 2020
From: report at bugs.python.org (Andrew Aladjev)
Date: Tue, 21 Jan 2020 10:10:44 +0000
Subject: [issue22724] byte-compile fails for cross-builds
In-Reply-To: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za>
Message-ID: <1579601444.71.0.0538330923684.issue22724@roundup.psfhosted.org>


Andrew Aladjev <aladjev.andrew at gmail.com> added the comment:

I've made a quick test of all patches provided. All patches have failed to fix it. The problem is more heavy than it looks like.

Please look at the following code:

PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir) _PYTHON_HOST_PLATFORM=$(_PYTHON_HOST_PLATFORM) PYTHONPATH=$(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)$(srcdir)/Lib _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_$(ABIFLAGS)_$(MACHDEP)_$(MULTIARCH) '${EPYTHON_FOR_BUILD:-${interp}}

It means that we will use "interp" to load cross compiled modules, env, etc from "_PYTHON_PROJECT_BASE". This code is broken by design. Loading of cross compiled modules, env, etc is not possible in general. For example you have different libc: glibc, musl, uclibc.

glibc -> cross compile -> glibc = loads fine.
musl -> cross compile -> musl = loads fine.
uclibc -> cross compile -> uclibc = loads fine.

glibc -> cross compile -> musl = failed to load.
glibc -> cross compile -> uclibc = failed to load.
musl -> cross compile -> glibc = failed to load.
musl -> cross compile -> uclibc = failed to load.
uclibc -> cross compile -> glibc = failed to load.
uclibc -> cross compile -> musl = failed to load.

Cross compilation doesn't mean only another arch, it means different libc, kernel headers, binutils and compiler. You will receive same issue while using clang toolchains.

Please assign this issue to python core developers. This issue can't be fixed by regular users without experience in python development. It requires complete change of cross compilation design.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22724>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:11:37 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jan 2020 10:11:37 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579601497.71.0.421586266757.issue32989@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset ec64640a2c5236d7a5d5470d759172a3d93eab0b by Terry Jan Reedy (Cheryl Sabella) in branch 'master':
bpo-32989: IDLE - fix bad editor call of pyparse method (GH-5968)
https://github.com/python/cpython/commit/ec64640a2c5236d7a5d5470d759172a3d93eab0b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:11:53 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Jan 2020 10:11:53 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579601513.04.0.0390359375768.issue32989@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17486
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/18096

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:12:01 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Jan 2020 10:12:01 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579601521.03.0.641936985552.issue32989@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17487
pull_request: https://github.com/python/cpython/pull/18097

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:12:39 2020
From: report at bugs.python.org (Ajay Tripathi)
Date: Tue, 21 Jan 2020 10:12:39 +0000
Subject: [issue39283] Add ability to inherit unittest arguement parser
In-Reply-To: <1578630738.78.0.369523186494.issue39283@roundup.psfhosted.org>
Message-ID: <1579601559.23.0.66237503861.issue39283@roundup.psfhosted.org>


Ajay Tripathi <ajay39in at gmail.com> added the comment:

Hi pual,

> The issue of testing a script that uses argparse has come up on StackOverFlow a number of times.

Sorry for the confusing but this is not a support ticket,
I am not stuck with a problem and I am aware of the variaous solutions on Stackoverflow to use arguements with unittest module.

Instead, I am proposing a change in the module so that the user of unittest can get the `parent_parser` and add their arguements in the unitest argparser instance itself.


I propose this change because it seems like a more intuitive way to use argparser with unittest to me and I hope to hear your thoughts on the change and if it is desired.



Best,
Ajay Tripathi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39283>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:14:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 10:14:17 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579601657.38.0.371431179998.issue39396@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 85ead4fc62829cb7ef2eb0af1a2933282f58c629 by Victor Stinner in branch 'master':
bpo-39396: Fix math.nextafter(-0.0, +0.0) on AIX 7.1 (GH-18094)
https://github.com/python/cpython/commit/85ead4fc62829cb7ef2eb0af1a2933282f58c629


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:18:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 10:18:14 +0000
Subject: [issue39396] AIX: self.assertEqualSign(math.nextafter(-0.0, +0.0),
 +0.0) test fails on AIX
In-Reply-To: <1579522842.97.0.0983912597487.issue39396@roundup.psfhosted.org>
Message-ID: <1579601894.14.0.094769656718.issue39396@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

My change should fix nextafter test failure on AIX.

Again, please open a separated issue for "FAIL: test_specific_values (test.test_cmath.CMathTests)".

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39396>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:25:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 10:25:20 +0000
Subject: [issue33387] Simplify bytecodes for try-finally,
 try-except and with blocks.
In-Reply-To: <1525026522.22.0.682650639539.issue33387@psf.upfronthosting.co.za>
Message-ID: <1579602320.33.0.820238540383.issue33387@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17488
pull_request: https://github.com/python/cpython/pull/18099

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33387>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:28:51 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Jan 2020 10:28:51 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579602531.7.0.891021049799.issue32989@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f3d3a3cc114ed30829544c3613b73e4fa6dd5599 by Miss Islington (bot) in branch '3.7':
bpo-32989: IDLE - fix bad editor call of pyparse method (GH-5968)
https://github.com/python/cpython/commit/f3d3a3cc114ed30829544c3613b73e4fa6dd5599


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:29:42 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Jan 2020 10:29:42 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579602582.7.0.628273263733.issue32989@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 060ad2fc1535adc76f96be8269b4af0f14429161 by Miss Islington (bot) in branch '3.8':
bpo-32989: IDLE - fix bad editor call of pyparse method (GH-5968)
https://github.com/python/cpython/commit/060ad2fc1535adc76f96be8269b4af0f14429161


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Tue Jan 21 05:57:50 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 21 Jan 2020 10:57:50 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579604270.05.0.0616126052682.issue39406@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Maybe use SetEnvironmentVariable() on Windows? 

`_wputenv` keeps Python's copy of the environment block in sync with CRT's copy, which in turn calls `SetEnvironmentVariableW` to sync with process environment block. The CRT's copy of the environment excludes and disallows variable names that start with "=". Because the interpreter initializes `os.environ` from the CRT environment, Python has never included or allowed 'hidden' variables such as "=C:". 

Switching to calling `SetEnvironmentVariableW` directly won't affect `os.system` and `os.spawnv[e]`, since the CRT calls `CreateProcessW` without overriding the process environment. However, have you considered the consequences for extension modules and embedding applications that use the CRT environment (e.g. `getenv`, `_wgetenv`) if the interpreter stops syncing with it? 

The concern that `[_w]putenv` doesn't copy the string does not apply to Windows.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 06:18:06 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 21 Jan 2020 11:18:06 +0000
Subject: [issue39397] Mac : fail to launch Python 3.8
In-Reply-To: <1579535856.72.0.329847745345.issue39397@roundup.psfhosted.org>
Message-ID: <1579605486.16.0.60014984152.issue39397@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The other locale related settings are off as well, the default system locale ends with ".UTF-8".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39397>
_______________________________________

From report at bugs.python.org  Tue Jan 21 06:19:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2020 11:19:38 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579605578.79.0.441594358998.issue39406@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This indeed a good argument to continue to use _wputenv. Thank you Eryk, you have saved us from making a mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 06:23:36 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 21 Jan 2020 11:23:36 +0000
Subject: [issue39409] AIX: FAIL: test_specific_values
 (test.test_cmath.CMathTests)
Message-ID: <1579605816.87.0.587336321661.issue39409@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Per message: https://bugs.python.org/issue39396#msg360362

opening new issue. Research (as requested) to follow.

----------
components: Tests
messages: 360389
nosy: Michael.Felt, vstinner
priority: normal
severity: normal
status: open
title: AIX: FAIL: test_specific_values (test.test_cmath.CMathTests)
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39409>
_______________________________________

From report at bugs.python.org  Tue Jan 21 06:25:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2020 11:25:31 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579605931.41.0.809833192556.issue39389@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset eab3b3f1c60afecfb4db3c3619109684cb04bd60 by Serhiy Storchaka (William Chargin) in branch 'master':
bpo-39389: gzip: fix compression level metadata (GH-18077)
https://github.com/python/cpython/commit/eab3b3f1c60afecfb4db3c3619109684cb04bd60


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Tue Jan 21 06:25:40 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Jan 2020 11:25:40 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579605940.57.0.36710270259.issue39389@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17489
pull_request: https://github.com/python/cpython/pull/18100

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Tue Jan 21 06:25:47 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Jan 2020 11:25:47 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579605947.12.0.125941302507.issue39389@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17490
pull_request: https://github.com/python/cpython/pull/18101

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Tue Jan 21 06:27:14 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2020 11:27:14 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579606034.69.0.870137878919.issue39389@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your contribution William!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Tue Jan 21 06:30:45 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 21 Jan 2020 11:30:45 +0000
Subject: [issue39408] Add support for SQLCipher
In-Reply-To: <1579599170.77.0.875579101001.issue39408@roundup.psfhosted.org>
Message-ID: <1579606245.58.0.468209344696.issue39408@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +berker.peksag, ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39408>
_______________________________________

From report at bugs.python.org  Tue Jan 21 06:42:52 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 21 Jan 2020 11:42:52 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579606972.73.0.790705042307.issue39389@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ab0d8e356ecd351d55f89519a6a97a1e69c0dfab by Miss Islington (bot) in branch '3.8':
bpo-39389: gzip: fix compression level metadata (GH-18077)
https://github.com/python/cpython/commit/ab0d8e356ecd351d55f89519a6a97a1e69c0dfab


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Tue Jan 21 06:47:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 11:47:33 +0000
Subject: [issue33387] Simplify bytecodes for try-finally,
 try-except and with blocks.
In-Reply-To: <1525026522.22.0.682650639539.issue33387@psf.upfronthosting.co.za>
Message-ID: <1579607253.76.0.497089416482.issue33387@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 629023c05be24fa2f01c914c739aaa5a61a0304c by Victor Stinner in branch 'master':
bpo-33387: Fix compiler warning in frame_block_unwind() (GH-18099)
https://github.com/python/cpython/commit/629023c05be24fa2f01c914c739aaa5a61a0304c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33387>
_______________________________________

From report at bugs.python.org  Tue Jan 21 07:01:13 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 21 Jan 2020 12:01:13 +0000
Subject: [issue37444] Differing exception between builtins and importlib when
 importing beyond top-level package
In-Reply-To: <1561749733.32.0.955430999512.issue37444@roundup.psfhosted.org>
Message-ID: <1579608073.2.0.728054996681.issue37444@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

While raising ImportError certainly makes much more sense in this case, this change is backwards incompatible and there was no DeprecationWarning. I don't consider that fair.

As a certain compromise, we could maybe raise a custom ImportError+ValueError offspring (e.g. BeyondToplevelImportError)?

If feeling fancy, we could rise a DeprecationWarning when issublcass(BeyondToplevelImportError, ValueError) is used?

----------
nosy: +hroncok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37444>
_______________________________________

From report at bugs.python.org  Tue Jan 21 07:53:42 2020
From: report at bugs.python.org (Igor Ceh)
Date: Tue, 21 Jan 2020 12:53:42 +0000
Subject: [issue39410] CentOS 6.10 SQLite 3.30.1 - _sqlite3 builds successfully
 but is removed because it cannot be imported.
Message-ID: <1579611222.47.0.288920213647.issue39410@roundup.psfhosted.org>


New submission from Igor Ceh <ceh.igor at outlook.com>:

While trying to build Python 3.8.1 from source with Sqlite 3.30.1 on a CentOS 6.10 I get the following warning:

*** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-x86_64-3.8/_sqlite3.cpython-38-x86_64-linux-gnu.so: undefined symbol: sqlite3_close_v2

The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc                  atexit                pwd
time


Failed to build these modules:
_uuid


Following modules built successfully but were removed because they could not be imported:
_sqlite3

If I try to import sqlite in python:
[vagrant at centos6 Python-3.8.1]$ ./python
Python 3.8.1 (default, Jan 21 2020, 04:22:59)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-23)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/src/Python-3.8.1/Lib/sqlite3/__init__.py", line 23, in <module>
    from sqlite3.dbapi2 import *
  File "/usr/local/src/Python-3.8.1/Lib/sqlite3/dbapi2.py", line 27, in <module>
    from _sqlite3 import *
ModuleNotFoundError: No module named '_sqlite3'
>>>

Also tried building with SQLite version 3.7.9 from atomic repository with same error.

----------
messages: 360395
nosy: cehovski
priority: normal
severity: normal
status: open
title: CentOS 6.10 SQLite 3.30.1 - _sqlite3 builds successfully but is removed because it cannot be imported.
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39410>
_______________________________________

From report at bugs.python.org  Tue Jan 21 08:14:50 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2020 13:14:50 +0000
Subject: [issue39408] Add support for SQLCipher
In-Reply-To: <1579599170.77.0.875579101001.issue39408@roundup.psfhosted.org>
Message-ID: <1579612490.2.0.148858064107.issue39408@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What exactly do you need to add and change in the sqlite module? The stdlib cannot depend on a third-party module. Ideally, you just create a subclass of some standard class and overrides a constructor and few methods.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39408>
_______________________________________

From report at bugs.python.org  Tue Jan 21 08:29:29 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 21 Jan 2020 13:29:29 +0000
Subject: [issue39411] pyclbr rewrite on AST
Message-ID: <1579613369.33.0.216761296366.issue39411@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

pyclbr currently uses token streams to analyze but it can be alot simpler with usage of AST. There are already many flaws, including some comments about limitations of this token stream processing. 

I have a draft about this. Initial PR wont change any behavior, it will just make code much simpler with the usage of AST (just an addition to Function about handling of async functions, is_async field). If agreed I can propose a second PR (or append the inital one) that will enhance Function/Class objects with various identifiers (like keywords, metaclasses, end position information etc.). The second PR will be alot easier to do thanks to AST.

----------
components: Library (Lib)
messages: 360397
nosy: Batuhan Taskaya, pablogsal
priority: normal
severity: normal
status: open
title: pyclbr rewrite on AST
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39411>
_______________________________________

From report at bugs.python.org  Tue Jan 21 08:40:05 2020
From: report at bugs.python.org (Batuhan)
Date: Tue, 21 Jan 2020 13:40:05 +0000
Subject: [issue39411] pyclbr rewrite on AST
In-Reply-To: <1579613369.33.0.216761296366.issue39411@roundup.psfhosted.org>
Message-ID: <1579614005.85.0.0726522566121.issue39411@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
keywords: +patch
pull_requests: +17491
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18103

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39411>
_______________________________________

From report at bugs.python.org  Tue Jan 21 08:45:54 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 21 Jan 2020 13:45:54 +0000
Subject: [issue39409] AIX: FAIL: test_specific_values
 (test.test_cmath.CMathTests)
In-Reply-To: <1579605816.87.0.587336321661.issue39409@roundup.psfhosted.org>
Message-ID: <1579614354.35.0.375142537719.issue39409@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39409>
_______________________________________

From report at bugs.python.org  Tue Jan 21 09:03:35 2020
From: report at bugs.python.org (Raymond Leiter)
Date: Tue, 21 Jan 2020 14:03:35 +0000
Subject: [issue39402] Consistent use of terms
In-Reply-To: <1579591189.8.0.172130610476.issue39402@roundup.psfhosted.org>
Message-ID: <CAPbG7+hPPHekn7PdXWgMWFrYtKy=BzBUgZ8uQn1ikDtU7KO2uQ@mail.gmail.com>


Raymond Leiter <rayrleiter at gmail.com> added the comment:

Ray;
Thanks for the reply.
I understand very well, your remarks -- and, in fact, agree with them.
I think my aversion to chaotic terminology stems from my study of BNF and
the joy of reading RFCs.
I'll send in suggestions if I find actual errors or really confusing
explanations of concepts.
Thanks again.
Ray

On Tue, Jan 21, 2020 at 2:19 AM Raymond Hettinger <report at bugs.python.org>
wrote:

>
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
>
> I don't think we would ever consider replacing "parentheses" with "round
> brackets".  Also, we have long talked about "curly braces" though the
> braces/brackets choice is a little loose.  Also note that greater-than or
> less-than have established usage (see the html entities or unicode code
> point name for example).
>
> > I'm well aware of the difficulty in garnering support for
> > this kind of an 'improvement', but I felt it needed said.
>
> I appreciate that.  Thanks for the suggestion, but we'll decline a
> wholesale search and replace mission.  If an individual case of known
> confusion arises, we can take a look at it, but for now we have no evidence
> that the current docs are causing confusion for end users.
>
> ----------
> nosy: +rhettinger
> resolution:  -> rejected
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39402>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39402>
_______________________________________

From report at bugs.python.org  Tue Jan 21 09:14:27 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 21 Jan 2020 14:14:27 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1579616067.52.0.12529655542.issue35943@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

> Do you mean that there is a risk that the backport introduces a regression in another part of the code? If yes, I would suggest to not backport the change to *stable* branches.

My worry are the many changes that are required to ceval to make this back port work. Not that I think we can not successfully backport things. we can.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Tue Jan 21 09:30:18 2020
From: report at bugs.python.org (Igor Ceh)
Date: Tue, 21 Jan 2020 14:30:18 +0000
Subject: [issue39410] CentOS 6.10 SQLite 3.30.1 - _sqlite3 builds successfully
 but is removed because it cannot be imported.
In-Reply-To: <1579611222.47.0.288920213647.issue39410@roundup.psfhosted.org>
Message-ID: <1579617018.95.0.688274566042.issue39410@roundup.psfhosted.org>


Igor Ceh <ceh.igor at outlook.com> added the comment:

I've changed ./Modules/_sqlite/util.h

//#if SQLITE_VERSION_NUMBER >= 3007014
#if SQLITE_VERSION_NUMBER >= 3107014 // Change
#define SQLITE3_CLOSE sqlite3_close_v2
#else
#define SQLITE3_CLOSE sqlite3_close
#endif

#endif

And tried to recompile with a new error:
*** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-x86_64-3.8/_sqlite3.cpython-38-x86_64-linux-gnu.so: undefined symbol: sqlite3_errstr                                                                                                                                                                                                                                                                                                                          The following modules found by detect_modules() in setup.py, have been                                                                                                                                                                       built by the Makefile instead, as configured by the Setup files:                                                                                                                                                                             _abc                  atexit                pwd
time


Failed to build these modules:
_uuid


Following modules built successfully but were removed because they could not be imported:
_sqlite3

Went into ./Modules/_sqlite/connection.c and also changed:
//#if SQLITE_VERSION_NUMBER > 3007015
#if SQLITE_VERSION_NUMBER > 3107015 // Change                                                                                                                                                                                                                      PyErr_SetString(pysqlite_OperationalError, sqlite3_errstr(rc));

With these changes the build was successful and I can import sqlite3. But I have no idea if this has any unforeseen consequences.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39410>
_______________________________________

From report at bugs.python.org  Tue Jan 21 09:34:24 2020
From: report at bugs.python.org (ccetsii)
Date: Tue, 21 Jan 2020 14:34:24 +0000
Subject: [issue39412] Install launcher for all users
Message-ID: <1579617264.58.0.64528608209.issue39412@roundup.psfhosted.org>


New submission from ccetsii <ccetsii at ull.edu.es>:

In Python 3.8.1 (32 bits) Windows Installer, the first page show a checkbox for "install launcher for all users (recommended)", but software install in user directory (see screenchot attachment).
Casually, in "customize installation" option, exist other "Install for all users" options, and that option works correctly.

----------
files: python_installer.png
messages: 360401
nosy: ccetsii
priority: normal
severity: normal
status: open
title: Install launcher for all users
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48857/python_installer.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39412>
_______________________________________

From report at bugs.python.org  Tue Jan 21 09:39:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 14:39:20 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
Message-ID: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

os.unsetenv() is documented to be available on Windows, but it's not.

In Python 3.8, "del os.environ[key]" is implemented as:

   os.putenv(key.upper(), "")

Attached PR implements it using SetEnvironmentVariableW(name, NULL).

----------
components: Library (Lib), Windows
messages: 360402
nosy: paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Implement os.unsetenv() on Windows
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Tue Jan 21 09:47:02 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 21 Jan 2020 14:47:02 +0000
Subject: [issue39411] pyclbr rewrite on AST
In-Reply-To: <1579613369.33.0.216761296366.issue39411@roundup.psfhosted.org>
Message-ID: <1579618022.49.0.840691577198.issue39411@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39411>
_______________________________________

From report at bugs.python.org  Tue Jan 21 09:53:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 14:53:09 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579618389.05.0.502205392142.issue39413@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17492
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18104

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Tue Jan 21 10:13:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 15:13:18 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579619598.31.0.537137344023.issue39413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 56cd3710a1ea3ba872d345ea1bebc86ed08bc8b8 by Victor Stinner in branch 'master':
bpo-39413: Implement os.unsetenv() on Windows (GH-18104)
https://github.com/python/cpython/commit/56cd3710a1ea3ba872d345ea1bebc86ed08bc8b8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Tue Jan 21 10:16:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 15:16:51 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579619811.54.0.283737298299.issue39413@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Tue Jan 21 10:27:01 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 21 Jan 2020 15:27:01 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579620421.05.0.136140493871.issue39413@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

This bypasses the CRT's copy of the environment. If any C code calls [_w]getenv, it will still see the variable defined. The only way it won't is if setting the value also bypassed the CRT environment by directly calling SetEnvironmentVariableW.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Tue Jan 21 10:29:21 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 21 Jan 2020 15:29:21 +0000
Subject: [issue39412] Install launcher for all users
In-Reply-To: <1579617264.58.0.64528608209.issue39412@roundup.psfhosted.org>
Message-ID: <1579620561.97.0.357339937136.issue39412@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39412>
_______________________________________

From report at bugs.python.org  Tue Jan 21 10:37:51 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 21 Jan 2020 15:37:51 +0000
Subject: [issue39412] Install launcher for all users
In-Reply-To: <1579617264.58.0.64528608209.issue39412@roundup.psfhosted.org>
Message-ID: <1579621071.74.0.964242220384.issue39412@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The py launcher is separate from individual installations of Python. However many versions of Python are installed at the system level and for however many users, the system needs only one installation of the launcher. That's why it's recommended to install for all users. 

If the current user can't elevate to administrator access, it's possible to choose to install the py launcher for just the current user. In this case it installs to the user's "%LocalAppData%\Programs\Python\Launcher" directory, and this directory is added to PATH.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39412>
_______________________________________

From report at bugs.python.org  Tue Jan 21 11:08:58 2020
From: report at bugs.python.org (Anders)
Date: Tue, 21 Jan 2020 16:08:58 +0000
Subject: [issue37909] Thread pool return ref hold memory
In-Reply-To: <1566420903.63.0.857548145971.issue37909@roundup.psfhosted.org>
Message-ID: <1579622938.32.0.959251955644.issue37909@roundup.psfhosted.org>


Anders <andersandjensen at gmail.com> added the comment:

Note: due to a change in Python 3.8 this example would be a lot less noticeable if tested. The problem remains the same though.

If you run this snippet with Python 3.7, which is before the thread reuse was introduced into the ThreadPoolExecutor, each thread will keep around 600mb of memory in use.

This can be solved by shutting down the ThreadPoolExecutor which this example does.

Now, the big problem is that asyncio uses a long-running ThreadPoolExecutor, per default, for run_in_executor. Those threads will stay around forever and consume memory until the application is shut down.

If you have a job that consumes a lot of memory for a short period of time and use any long-running ThreadPoolExecutor then the memory will just keep growing as the job hits various threads that are never cleaned up.

----------
import asyncio
import concurrent
import threading


def prepare_a_giant_list():
    d = {}
    for i in range(1000):
        d[i] = {}
        for j in range(1000):
            d[i][j] = {}
            for k in range(30):
                d[i][j][k] = 'a' * 1000
    del d

    th_num = threading.active_count()
    print("Thread number is {}".format(th_num))


async def main():
    loop = asyncio.get_running_loop()
    with concurrent.futures.ThreadPoolExecutor(max_workers=20) as async_executor:
        await loop.run_in_executor(async_executor, prepare_a_giant_list)
        await asyncio.sleep(5)
        await loop.run_in_executor(async_executor, prepare_a_giant_list)
        await asyncio.sleep(5)
        await loop.run_in_executor(async_executor, prepare_a_giant_list)
        await asyncio.sleep(5)
        await loop.run_in_executor(async_executor, prepare_a_giant_list)
        await asyncio.sleep(5)
    print('Done!')
    await asyncio.sleep(15)


if __name__ == "__main__":
    asyncio.run(main())
----------

----------
nosy: +johndoee
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37909>
_______________________________________

From report at bugs.python.org  Tue Jan 21 11:54:15 2020
From: report at bugs.python.org (SilentGhost)
Date: Tue, 21 Jan 2020 16:54:15 +0000
Subject: [issue39407] Bitfield Union does not work for bit widths greater than
 8 bits
In-Reply-To: <1579598446.4.0.992885601922.issue39407@roundup.psfhosted.org>
Message-ID: <1579625655.77.0.422074725728.issue39407@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39407>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:04:43 2020
From: report at bugs.python.org (SilentGhost)
Date: Tue, 21 Jan 2020 17:04:43 +0000
Subject: [issue39410] CentOS 6.10 SQLite 3.30.1 - _sqlite3 builds successfully
 but is removed because it cannot be imported.
In-Reply-To: <1579611222.47.0.288920213647.issue39410@roundup.psfhosted.org>
Message-ID: <1579626283.49.0.62994207896.issue39410@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib)
nosy: +ghaering
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39410>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:07:47 2020
From: report at bugs.python.org (Reece Dunham)
Date: Tue, 21 Jan 2020 17:07:47 +0000
Subject: [issue39414] Multiprocessing resolving object as None
Message-ID: <1579626467.92.0.021176656048.issue39414@roundup.psfhosted.org>


New submission from Reece Dunham <me at rdil.rocks>:

Exception ignored in: <function Pool.__del__ at 0x7ffbaf47d9d0>
Traceback (most recent call last):
  File "/root/conda/lib/python3.8/multiprocessing/pool.py", line 268, in __del__
  File "/root/conda/lib/python3.8/multiprocessing/queues.py", line 362, in put
AttributeError: 'NoneType' object has no attribute 'dumps'

Pretty sure that shouldn't be None.

----------
components: Library (Lib)
messages: 360407
nosy: rdil
priority: normal
severity: normal
status: open
title: Multiprocessing resolving object as None
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39414>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:09:17 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 21 Jan 2020 17:09:17 +0000
Subject: [issue39415] Remove unused code from longobject.c complexobject.c
 floatobject.c
Message-ID: <1579626557.12.0.506722213055.issue39415@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

For example, long_is_finite has not been used for 12 years.

----------
assignee: corona10
messages: 360408
nosy: corona10
priority: normal
severity: normal
status: open
title: Remove unused code from longobject.c complexobject.c floatobject.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39415>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:09:30 2020
From: report at bugs.python.org (Reece Dunham)
Date: Tue, 21 Jan 2020 17:09:30 +0000
Subject: [issue39414] Multiprocessing resolving object as None
In-Reply-To: <1579626467.92.0.021176656048.issue39414@roundup.psfhosted.org>
Message-ID: <1579626570.21.0.548517251937.issue39414@roundup.psfhosted.org>


Change by Reece Dunham <me at rdil.rocks>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39414>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:14:28 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 21 Jan 2020 17:14:28 +0000
Subject: [issue39414] Multiprocessing resolving object as None
In-Reply-To: <1579626467.92.0.021176656048.issue39414@roundup.psfhosted.org>
Message-ID: <1579626868.1.0.624605476483.issue39414@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

If you don't mind, Would you like to attach the reproducible script for this?

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39414>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:16:12 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 21 Jan 2020 17:16:12 +0000
Subject: [issue39145] Innocuous parent class changes multiple inheritance MRO
In-Reply-To: <1577499717.77.0.3384206838.issue39145@roundup.psfhosted.org>
Message-ID: <1579626972.98.0.821112179345.issue39145@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17493
pull_request: https://github.com/python/cpython/pull/18105

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39145>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:18:10 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 21 Jan 2020 17:18:10 +0000
Subject: [issue39415] Remove unused code from longobject.c complexobject.c
 floatobject.c
In-Reply-To: <1579626557.12.0.506722213055.issue39415@roundup.psfhosted.org>
Message-ID: <1579627090.68.0.789596592606.issue39415@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17494
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18105

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39415>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:18:47 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 21 Jan 2020 17:18:47 +0000
Subject: [issue39145] Innocuous parent class changes multiple inheritance MRO
In-Reply-To: <1577499717.77.0.3384206838.issue39145@roundup.psfhosted.org>
Message-ID: <1579627127.12.0.898875770267.issue39145@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests:  -17493

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39145>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:23:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 17:23:34 +0000
Subject: [issue38856] wait_closed() can raise ConnectionResetError
In-Reply-To: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>
Message-ID: <1579627414.33.0.0233777680548.issue38856@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Why is this issue marked as a release blocker? Is it a Python 3.8 regression, or just a regular bug?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:24:14 2020
From: report at bugs.python.org (Reece Dunham)
Date: Tue, 21 Jan 2020 17:24:14 +0000
Subject: [issue39414] Multiprocessing resolving object as None
In-Reply-To: <1579626467.92.0.021176656048.issue39414@roundup.psfhosted.org>
Message-ID: <1579627454.43.0.665676380973.issue39414@roundup.psfhosted.org>


Reece Dunham <me at rdil.rocks> added the comment:

Not sure exactly where its being thrown, but I know it happened in https://cirrus-ci.com/task/4875001270632448?command=test_pyside2#L3974

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39414>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:25:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 17:25:08 +0000
Subject: [issue38856] asyncio ProactorEventLoop: wait_closed() can raise
 ConnectionResetError
In-Reply-To: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>
Message-ID: <1579627508.19.0.71231067129.issue38856@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: wait_closed() can raise ConnectionResetError -> asyncio ProactorEventLoop: wait_closed() can raise ConnectionResetError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:25:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 17:25:24 +0000
Subject: [issue38856] asyncio ProactorEventLoop: wait_closed() can raise
 ConnectionResetError
In-Reply-To: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>
Message-ID: <1579627524.69.0.784540277752.issue38856@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
components: +Windows, asyncio
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:26:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 17:26:23 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579627583.24.0.206248289355.issue38076@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> https://github.com/python/cpython/pull/18038 is a partial fix for this

Is it enough to reduce the issue priority from release blocker to normal?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:34:42 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 21 Jan 2020 17:34:42 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579628082.0.0.0950428269331.issue38076@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Is it enough to reduce the issue priority from release blocker to normal?

The error can still happened in other modules and under similar conditions, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:36:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 17:36:19 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579628179.59.0.926370808944.issue38076@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The error can still happened in other modules and under similar conditions, no?

The question was if the next 3.9 *alpha* release must be blocked by this issue. I don't think so. I reduce the priority to normal (not set). If someone disagrees, feel free to raise it again to release blocker ;-)

----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:39:28 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Tue, 21 Jan 2020 17:39:28 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579628368.81.0.0585209198003.issue38076@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

The PR that I sent out already fixes the issue. @vstinner, @pablogsal, please take a look again https://github.com/python/cpython/pull/18039

That should close this issue, no need to work around the bug priority.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:42:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 17:42:03 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579628523.45.0.932574375502.issue38076@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> That should close this issue, no need to work around the bug priority.

I'm concerned by release blocker because 3.9.0a3 version is supposed to be released soon, and usually release blocker do block a release :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:46:44 2020
From: report at bugs.python.org (Eddie Elizondo)
Date: Tue, 21 Jan 2020 17:46:44 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579628804.27.0.323275318554.issue38076@roundup.psfhosted.org>


Eddie Elizondo <eduardo.elizondorueda at gmail.com> added the comment:

> I'm concerned by release blocker because 3.9.0a3 version is supposed to be released soon, and usually release blocker do block a release :-)

Ah! That makes sense!

In any case, feel free to ping me if you need help on my side to get this PR through (or to remove the release blocker).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Tue Jan 21 12:56:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 17:56:45 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579629405.11.0.856376885606.issue39406@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17495
pull_request: https://github.com/python/cpython/pull/18106

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 13:04:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 18:04:18 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579629858.21.0.347879702331.issue39413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> This bypasses the CRT's copy of the environment. If any C code calls [_w]getenv, it will still see the variable defined. The only way it won't is if setting the value also bypassed the CRT environment by directly calling SetEnvironmentVariableW.

Oh. That's a valid concern. I reopen the issue.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Tue Jan 21 13:08:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 18:08:46 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579630126.23.0.178592769359.issue39406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-39413 "Implement os.unsetenv() on Windows" to prepare work on this issue. But Eryk raised the same concern about CRT: https://bugs.python.org/issue39413#msg360404

I wasn't aware of that :-/

> `_wputenv` keeps Python's copy of the environment block in sync with CRT's copy, which in turn calls `SetEnvironmentVariableW` to sync with process environment block. The CRT's copy of the environment excludes and disallows variable names that start with "=". Because the interpreter initializes `os.environ` from the CRT environment, Python has never included or allowed 'hidden' variables such as "=C:". 

My main motivation to use SetEnvironmentVariableW() on Windows is to avoid bpo-39395. Do you mean that Windows _putenv() is not affected by bpo-39395: Python can safely removes the string to _putenv() just after the call?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 13:16:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 18:16:30 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579630590.53.0.277294200585.issue39413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I checked the doc: _putenv("VAR=") removes the environment variable "VAR". It's well documented:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/putenv-wputenv?view=vs-2019

"You can remove a variable from the environment by specifying an empty value_string, or in other words, by specifying only varname=."

So Python 3.8 os._unsetenv() is correct, but this function was not exposed, and so this issue remains relevant: Python 3.8 documents that os.unsetenv() is available on Windows, but it's not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Tue Jan 21 13:25:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 18:25:46 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579631146.44.0.137981089034.issue39406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 623ed6171eae35af7fd2e804dfd9c832c05c5d48 by Victor Stinner in branch 'master':
bpo-39406: Add PY_PUTENV_DICT macro to posixmodule.c (GH-18106)
https://github.com/python/cpython/commit/623ed6171eae35af7fd2e804dfd9c832c05c5d48


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 13:29:42 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2020 18:29:42 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579631382.14.0.192361039807.issue39406@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There is also _wputenv_s which affects _spawn, _exec and system.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 13:30:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 18:30:04 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579631404.9.0.496712281087.issue39413@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17496
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/18107

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Tue Jan 21 13:31:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 18:31:10 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579631470.62.0.320987477951.issue39413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

PR 18107 still fix this issue (add os.unsetenv() to Python 3.9 on Windows), but fix the implementation (use _wputenv() rather than SetEnvironmentVariableW(), to update the CRT).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Tue Jan 21 13:32:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 21 Jan 2020 18:32:37 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579631557.53.0.919727466653.issue39413@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17497
pull_request: https://github.com/python/cpython/pull/18108

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Tue Jan 21 13:42:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2020 18:42:22 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579632142.19.0.0161873325618.issue39406@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Why posix_putenv_garbage was renamed to putenv_dict?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 13:56:30 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2020 18:56:30 +0000
Subject: [issue39415] Remove unused code from longobject.c complexobject.c
 floatobject.c
In-Reply-To: <1579626557.12.0.506722213055.issue39415@roundup.psfhosted.org>
Message-ID: <1579632990.05.0.813392481064.issue39415@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

A patch was proposed in issue18842.

----------
nosy: +martin.panter, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39415>
_______________________________________

From report at bugs.python.org  Tue Jan 21 14:05:51 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 21 Jan 2020 19:05:51 +0000
Subject: [issue39409] AIX: FAIL: test_specific_values
 (test.test_cmath.CMathTests)
In-Reply-To: <1579605816.87.0.587336321661.issue39409@roundup.psfhosted.org>
Message-ID: <1579633551.29.0.753784148086.issue39409@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Similar previous issues on macOS: #18513, #15477.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39409>
_______________________________________

From report at bugs.python.org  Tue Jan 21 14:16:09 2020
From: report at bugs.python.org (Manuel Barkhau)
Date: Tue, 21 Jan 2020 19:16:09 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579634169.68.0.670889347143.issue39390@roundup.psfhosted.org>


Manuel Barkhau <mbarkhau at gmail.com> added the comment:

Is there anything I can do to help move this forward?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Tue Jan 21 14:46:51 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 21 Jan 2020 19:46:51 +0000
Subject: [issue37909] Thread pool return ref hold memory
In-Reply-To: <1566420903.63.0.857548145971.issue37909@roundup.psfhosted.org>
Message-ID: <1579636011.23.0.00204257566446.issue37909@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The latest example releases allocated python objects.
The memory is returned to allocator which, in turn, can hold it for a while. The allocator is not controlled by Python API.

Anyway, if an explicit executor solves your needs -- please just use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37909>
_______________________________________

From report at bugs.python.org  Tue Jan 21 15:09:11 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 21 Jan 2020 20:09:11 +0000
Subject: [issue39415] Remove unused code from longobject.c complexobject.c
 floatobject.c
In-Reply-To: <1579626557.12.0.506722213055.issue39415@roundup.psfhosted.org>
Message-ID: <1579637351.44.0.401628729393.issue39415@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39415>
_______________________________________

From report at bugs.python.org  Tue Jan 21 15:13:04 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 21 Jan 2020 20:13:04 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579637584.06.0.349811795921.issue39353@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I agree with deprecating binhex.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Tue Jan 21 15:13:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2020 20:13:36 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579637616.29.0.225512056187.issue39390@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Tue Jan 21 15:13:46 2020
From: report at bugs.python.org (Sebastian Noack)
Date: Tue, 21 Jan 2020 20:13:46 +0000
Subject: [issue39408] Add support for SQLCipher
In-Reply-To: <1579599170.77.0.875579101001.issue39408@roundup.psfhosted.org>
Message-ID: <1579637626.75.0.197981304003.issue39408@roundup.psfhosted.org>


Sebastian Noack <sebastian.noack at gmail.com> added the comment:

Well, the stdlib already depends on a third-party library here, i.e. SQLite3. SQLCipher is a drop-in replacement for SQLite3 that adds support for encrypted databases. In order to use SQLCipher, I'd have to build the sqlite3 module against SQLCipher (instead of SQLite3). As it's a drop-in replacement, no further changes are required (unless rather than having SQLCipher bindings exposed as a separate module, we want enable it through an argument in sqlite3.connect).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39408>
_______________________________________

From report at bugs.python.org  Tue Jan 21 15:23:45 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 21 Jan 2020 20:23:45 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579638225.82.0.24103853588.issue39390@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Should not copytree convert arguments of the ignore callback to str and list correspondingly?

It should. I think it makes sense to just do this for Python 3.8.2 instead of updating the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Tue Jan 21 15:33:51 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2020 20:33:51 +0000
Subject: [issue39408] Add support for SQLCipher
In-Reply-To: <1579599170.77.0.875579101001.issue39408@roundup.psfhosted.org>
Message-ID: <1579638831.82.0.457796769311.issue39408@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If SQLCipher is a drop-in replacement, perhaps the simplest way is to use LD_LIBRARY_PATH to replace libsqlite3.

You can also insert a path to your build of the _sqlite module in sys.path before standard paths.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39408>
_______________________________________

From report at bugs.python.org  Tue Jan 21 16:12:28 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 21 Jan 2020 21:12:28 +0000
Subject: [issue37444] Differing exception between builtins and importlib when
 importing beyond top-level package
In-Reply-To: <1561749733.32.0.955430999512.issue37444@roundup.psfhosted.org>
Message-ID: <1579641148.94.0.843423153333.issue37444@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

There's no deprecation warning because how do you warn about that? You raise DeprecationWarning about an exception you have yet to raise?

And I personally think calling this unfair is a bit harsh.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37444>
_______________________________________

From report at bugs.python.org  Tue Jan 21 16:17:23 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 21 Jan 2020 21:17:23 +0000
Subject: [issue37444] Differing exception between builtins and importlib when
 importing beyond top-level package
In-Reply-To: <1561749733.32.0.955430999512.issue37444@roundup.psfhosted.org>
Message-ID: <1579641443.25.0.415164645632.issue37444@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

I know that raising a DeprecationWarning here is most likely not possible or too black-magical to do. My intention was not to be harsh, sorry about that. I just wanted to point out that a backwards incompatible behavior like this without a (possible) deprecation warning might not counterweigh the gain of raising the logical exception type. As a compromise, I proposed to raise a hybrid that inherits from both.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37444>
_______________________________________

From report at bugs.python.org  Tue Jan 21 16:29:39 2020
From: report at bugs.python.org (Manuel Barkhau)
Date: Tue, 21 Jan 2020 21:29:39 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579642179.81.0.94914280978.issue39390@roundup.psfhosted.org>


Manuel Barkhau <mbarkhau at gmail.com> added the comment:

Unless somebody else wants to, I could have a go at an PR to update shutil.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Tue Jan 21 17:24:15 2020
From: report at bugs.python.org (Peter Donis)
Date: Tue, 21 Jan 2020 22:24:15 +0000
Subject: [issue1812] doctest _load_testfile function -- newline handling seems
 incorrect
In-Reply-To: <1200117455.4.0.563963262174.issue1812@psf.upfronthosting.co.za>
Message-ID: <1579645455.2.0.153277010193.issue1812@roundup.psfhosted.org>


Peter Donis <peterdonis at alum.mit.edu> added the comment:

Pinging as a reminder that there is a pull request for this issue awaiting review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1812>
_______________________________________

From report at bugs.python.org  Tue Jan 21 17:31:20 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 21 Jan 2020 22:31:20 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579645880.05.0.217546184964.issue39390@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Yes, thanks. Whoever got bit by this is either getting an exception or not the intended behavior (due to failed string comparison). I doubt anybody is relying on the new type checking since it's not documented. If they are, they are probably just doing:

    def callback(name, names):
        if not isinstance(name, str):  # bugfix 3.8
            name = name.name
        ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Tue Jan 21 17:38:25 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 21 Jan 2020 22:38:25 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579646305.08.0.532142525386.issue39390@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Tue Jan 21 18:30:02 2020
From: report at bugs.python.org (Sebastian Noack)
Date: Tue, 21 Jan 2020 23:30:02 +0000
Subject: [issue39408] Add support for SQLCipher
In-Reply-To: <1579599170.77.0.875579101001.issue39408@roundup.psfhosted.org>
Message-ID: <1579649402.81.0.570545701637.issue39408@roundup.psfhosted.org>


Sebastian Noack <sebastian.noack at gmail.com> added the comment:

Yes, I could use LD_LIBRARY_PATH (after copying /usr/lib/libsqlcipher.so.0 to /some/folder/libsqlite3.so), or alternatively LD_PRELOAD, and the sqlite3 stdlib module will just work as-is with SQLCipher. The latter is in fact what I'm doing at the moment, but this is quite a hack, and it's not portable to macOS or Windows.

Alternatively, I could fork the sqlite3 stdlib module, have it built against SQLCipher, and redistribute it. But I'd rather not go there.

That's why I'd love to see built-in support for SQLCipher in upstream Python, and as it is a drop-in replacement for SQLite3 which the stdlib already comes with bindings for, it seems to be a fairly small change on your end.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39408>
_______________________________________

From report at bugs.python.org  Tue Jan 21 19:13:03 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 22 Jan 2020 00:13:03 +0000
Subject: [issue31405] shutil.which doesn't find files without PATHEXT
 extension on Windows
In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za>
Message-ID: <1579651983.59.0.92414163254.issue31405@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

should I open a new issue for this, or is this an appropriate task to add to this discussion

shutil.which also doesn't apply `PATHEXT` when the path contains a directory separator

C:\Users\IEUser\astpretty>venv\Scripts\python --version
Python 3.7.5

C:\Users\IEUser\astpretty>venv\Scripts\python -c "import shutil; print(repr(shutil.which(r'venv\Scripts\python')))"
None

C:\Users\IEUser\astpretty>venv\Scripts\python -c "import shutil; print(repr(shutil.which(r'venv\Scripts\python.exe')))"
'venv\\Scripts\\python.exe'

----------
nosy: +Anthony Sottile

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31405>
_______________________________________

From report at bugs.python.org  Tue Jan 21 19:50:05 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 22 Jan 2020 00:50:05 +0000
Subject: [issue39375] Document os.environ[x] = y and os.putenv() as thread
 unsafe
In-Reply-To: <1579307768.04.0.648412303004.issue39375@roundup.psfhosted.org>
Message-ID: <1579654205.79.0.796989482619.issue39375@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: https://bugs.python.org/msg360245

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39375>
_______________________________________

From report at bugs.python.org  Tue Jan 21 20:19:48 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 22 Jan 2020 01:19:48 +0000
Subject: [issue39411] pyclbr rewrite using AST
In-Reply-To: <1579613369.33.0.216761296366.issue39411@roundup.psfhosted.org>
Message-ID: <1579655988.32.0.531345851675.issue39411@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Nice.  A few notes.

Docs: The initial doc paragraph now has 'module browser' rather than 'class browser'.  The change is needed 2 other places.  Could be part of this PR or another one.
* Chapter title: "Python class browser support".  The only instance of 'class browser' in the chapter.
* Module index: "Supports information extraction for a Python class browser."

Possible API changes based on IDLE module browser experience:

1. IDLE filters out the import nodes.  It would be nicer to not have to delete them by passing something like 'imports=False' (with True being the default for back compatibility).

2. With nested classes and functions added, the returned object is almost a tree of nodes, except that what should be the top 'Module' node is instead what should be its children dict.  This un-uniformity gets in the way of recursively processing the tree.

3. If there were a function that returned a Module node with its path and name, the same could be removed from all children except for new ImpClass nodes representing imported classes when imports=True.  Since users know the module passed to pyclbr, this might be true even without Module nodes.

4. If a user immediately inserts nodes into a tree widget, then the user may only need a iterator of minimal nodes (name, parent, startline).  This is enough when using tkinter.ttk.Treeview.   I have thought of doing this for IDLE by either simplifying a copy of the pyclbr code or traversing the AST, as the PR here does.  This would let top-level items appear in the widget as they are scanned instead of waiting until scanning is complete.

----------
nosy: +terry.reedy
title: pyclbr rewrite on AST -> pyclbr rewrite using AST

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39411>
_______________________________________

From report at bugs.python.org  Tue Jan 21 21:15:30 2020
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 22 Jan 2020 02:15:30 +0000
Subject: [issue18819] tarfile fills devmajor and devminor fields even for
 non-devices
In-Reply-To: <1377244570.17.0.881759543234.issue18819@psf.upfronthosting.co.za>
Message-ID: <1579659330.69.0.474161649143.issue18819@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Thanks for moving this issue forward, William!

----------
assignee:  -> ethan.furman
stage: patch review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18819>
_______________________________________

From report at bugs.python.org  Tue Jan 21 21:35:29 2020
From: report at bugs.python.org (Karl O. Pinc)
Date: Wed, 22 Jan 2020 02:35:29 +0000
Subject: [issue39416] Document default numeric string formats
Message-ID: <1579660529.58.0.0341841917197.issue39416@roundup.psfhosted.org>


New submission from Karl O. Pinc <kop at karlpinc.com>:

Seems sane to put _some_ restrictions on the string representations of the Numeric classes.  This would be a change to the Python language
specification.

Suggestions made in a pull request.

See the email thread:
Subject: Documenting Python's float.__str__()
https://mail.python.org/archives/list/python-dev at python.org/thread/FV22TKT3S2Q3P7PNN6MCXI6IX3HRRNAL/

----------
assignee: docs at python
components: Documentation
messages: 360442
nosy: docs at python, kop
priority: normal
severity: normal
status: open
title: Document default numeric string formats

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39416>
_______________________________________

From report at bugs.python.org  Tue Jan 21 21:38:40 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 22 Jan 2020 02:38:40 +0000
Subject: [issue39408] Add support for SQLCipher
In-Reply-To: <1579599170.77.0.875579101001.issue39408@roundup.psfhosted.org>
Message-ID: <1579660720.12.0.63211491276.issue39408@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

It might help if you show the change you actually propose.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39408>
_______________________________________

From report at bugs.python.org  Tue Jan 21 21:42:00 2020
From: report at bugs.python.org (Karl O. Pinc)
Date: Wed, 22 Jan 2020 02:42:00 +0000
Subject: [issue39416] Document default numeric string formats
In-Reply-To: <1579660529.58.0.0341841917197.issue39416@roundup.psfhosted.org>
Message-ID: <1579660920.02.0.938883889901.issue39416@roundup.psfhosted.org>


Change by Karl O. Pinc <kop at karlpinc.com>:


----------
keywords: +patch
pull_requests: +17498
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18111

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39416>
_______________________________________

From report at bugs.python.org  Tue Jan 21 21:49:38 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 22 Jan 2020 02:49:38 +0000
Subject: [issue39415] Remove unused code from longobject.c complexobject.c
 floatobject.c
In-Reply-To: <1579626557.12.0.506722213055.issue39415@roundup.psfhosted.org>
Message-ID: <1579661378.86.0.618045998651.issue39415@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 0d5eac8c327251f8edde5261cee43975d81311f6 by Benjamin Peterson (Dong-hee Na) in branch 'master':
closes bpo-39415: Remove unused codes from longobject.c complexobject.c floatobject.c. (GH-18105)
https://github.com/python/cpython/commit/0d5eac8c327251f8edde5261cee43975d81311f6


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39415>
_______________________________________

From report at bugs.python.org  Tue Jan 21 21:49:45 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Jan 2020 02:49:45 +0000
Subject: [issue39415] Remove unused code from longobject.c complexobject.c
 floatobject.c
In-Reply-To: <1579626557.12.0.506722213055.issue39415@roundup.psfhosted.org>
Message-ID: <1579661385.27.0.38561403048.issue39415@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17499
pull_request: https://github.com/python/cpython/pull/18112

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39415>
_______________________________________

From report at bugs.python.org  Tue Jan 21 22:06:50 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Jan 2020 03:06:50 +0000
Subject: [issue39415] Remove unused code from longobject.c complexobject.c
 floatobject.c
In-Reply-To: <1579626557.12.0.506722213055.issue39415@roundup.psfhosted.org>
Message-ID: <1579662410.33.0.911159844011.issue39415@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17500
pull_request: https://github.com/python/cpython/pull/18113

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39415>
_______________________________________

From report at bugs.python.org  Tue Jan 21 22:22:06 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 22 Jan 2020 03:22:06 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579663326.31.0.918693669734.issue39406@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Python can safely removes the string to _putenv() just after the call? 

Windows ucrt copies the buffer that's passed to _[w]putenv. This makes it non-compliant with POSIX but easier to use in this case. Here's an example using ctypes:

    >>> ucrt = ctypes.CDLL('ucrtbase')
    >>> buf = ctypes.create_unicode_buffer('spam=eggs')
    >>> ucrt._wputenv(buf)
    0

Directly modifying the buffer has no effect on the _wgetenv result:

    >>> buf[5] = 'a'
    >>> ucrt._wgetenv.restype = ctypes.POINTER(ctypes.c_wchar)
    >>> ucrt._wgetenv('spam')[:4]
    'eggs'

Linux putenv complies with POSIX, so changing "eggs" to "aggs" in the buffer does affect the getenv result in Linux. 

On the other hand, ucrt's [_w]getenv does not copy the environment string. For example:

    >>> p1 = ucrt._wgetenv('spam')
    >>> p1[0] = 'o'

    >>> p2 = ucrt._wgetenv('spam')
    >>> p2[:4]
    'oggs'

[_w]getenv is not thread safe. Even though all calls that access the ucrt environment are internally synchronized on a common lock, accessing the *result* from [_w]getenv still needs to be synchronized with concurrent _[w]putenv calls in a multithreaded process. Better still, use [_w]getenv_s or _[w]dupenv_s, which returns a copy.

> There is also _wputenv_s which affects _spawn, _exec and system.

The documentation is perhaps misleading. When a variable is set with _[w]putenv[_s], it also sets the variable in the process environment block to stay in sync. This indirectly affects _spawn*, _exec* and system(). common_spawnv (in ucrt\exec\spawnv.cpp), which implements the latter functions, calls CreateProcess with lpEnvironment as NULL (i.e.  inherit the current process environment), unless the caller passes a new environment (e.g. envp of spawnve).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Tue Jan 21 22:26:38 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Jan 2020 03:26:38 +0000
Subject: [issue39415] Remove unused code from longobject.c complexobject.c
 floatobject.c
In-Reply-To: <1579626557.12.0.506722213055.issue39415@roundup.psfhosted.org>
Message-ID: <1579663598.45.0.409395940485.issue39415@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a755410e054e1e2390de5830befc08fe80706c66 by Miss Islington (bot) in branch '3.8':
closes bpo-39415: Remove unused codes from longobject.c complexobject.c floatobject.c. (GH-18105)
https://github.com/python/cpython/commit/a755410e054e1e2390de5830befc08fe80706c66


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39415>
_______________________________________

From report at bugs.python.org  Tue Jan 21 23:16:51 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jan 2020 04:16:51 +0000
Subject: [issue18842] Add float.is_finite is_nan is_infinite to match Decimal
 methods
In-Reply-To: <1377532757.24.0.123652540945.issue18842@psf.upfronthosting.co.za>
Message-ID: <1579666611.04.0.299750076443.issue18842@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

rm-finite.patch was applied by bpo-39415.

> Once that's merged, let's close this issue as rejected.

I close this issue to a rejected state as discussed above.
Thank you to all who participated in this discussion.

----------
nosy: +corona10
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18842>
_______________________________________

From report at bugs.python.org  Tue Jan 21 23:18:14 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jan 2020 04:18:14 +0000
Subject: [issue39415] Remove unused code from longobject.c complexobject.c
 floatobject.c
In-Reply-To: <1579626557.12.0.506722213055.issue39415@roundup.psfhosted.org>
Message-ID: <1579666694.12.0.48342993169.issue39415@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Thank you to all who participated in this discussion and review :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39415>
_______________________________________

From report at bugs.python.org  Wed Jan 22 01:09:41 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 22 Jan 2020 06:09:41 +0000
Subject: [issue39416] Document default numeric string formats
In-Reply-To: <1579660529.58.0.0341841917197.issue39416@roundup.psfhosted.org>
Message-ID: <1579673381.27.0.219895994404.issue39416@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Is the lack of this documentation causing some confusion somewhere? This isn't rhetorical, I'm genuinely curious what problem you're trying to solve.

Is there any mainstream programming language where the basics of what you've laid out aren't true? It all seems pretty obvious to me. For example, I can't see anyone looking at this and saying "Ah, base 10. That's why it's producing the output I'm seeing."

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39416>
_______________________________________

From report at bugs.python.org  Wed Jan 22 01:35:21 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 22 Jan 2020 06:35:21 +0000
Subject: [issue39375] Document os.environ[x] = y and os.putenv() as thread
 unsafe
In-Reply-To: <1579307768.04.0.648412303004.issue39375@roundup.psfhosted.org>
Message-ID: <1579674921.2.0.0321228158472.issue39375@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

fwiw, no need to remove that message.  We'll want to make the docs clear that this does not apply to Windows.  :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39375>
_______________________________________

From report at bugs.python.org  Wed Jan 22 03:11:06 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 22 Jan 2020 08:11:06 +0000
Subject: [issue39375] Document os.environ[x] = y and os.putenv() as thread
 unsafe
In-Reply-To: <1579307768.04.0.648412303004.issue39375@roundup.psfhosted.org>
Message-ID: <1579680666.57.0.709218108157.issue39375@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> no need to remove that message.  

I was discussing the wrong API. It's not directly relevant that Windows API functions that access the process environment are protected by the PEB lock. Python primarily uses [_w]environ, a copy of the process environment that's managed by the C runtime library (ucrt). os.putenv modifies this environment via _wputenv. (Ultimately this syncs with the process environment by calling SetEnvironmentVariableW.)

Functions that modify and read ucrt's environment are protected by a lock. But there's still a concern if multithreaded code reads or modifies [_w]environ concurrent to a _[w]putenv call. Also, [_w]getenv returns a pointer to the value in [_w]environ, so it has the same problem. A significant difference, however, is that _[w]putenv in ucrt is not POSIX compliant, since it copies the caller's string. Also, ucrt has safer [_w]getenv_s and _[w]dupenv_s functions that return a copy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39375>
_______________________________________

From report at bugs.python.org  Wed Jan 22 03:27:19 2020
From: report at bugs.python.org (Justin Capella)
Date: Wed, 22 Jan 2020 08:27:19 +0000
Subject: [issue38860] GenericPyCData_new does not invoke new or init
In-Reply-To: <1574217244.17.0.279528403217.issue38860@roundup.psfhosted.org>
Message-ID: <1579681639.56.0.313306582793.issue38860@roundup.psfhosted.org>


Justin Capella <justincapella at gmail.com> added the comment:

Becca were you still interested in this issue? 

Anyone agree the unit test seems to have a bug if that is intended behavior?

Is there a better forum for discussion about design/behavior, maybe the more generic issue of GenericPyCData_new using tp_alloc instead of tp_new

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38860>
_______________________________________

From report at bugs.python.org  Wed Jan 22 04:04:31 2020
From: report at bugs.python.org (Sebastien Foo)
Date: Wed, 22 Jan 2020 09:04:31 +0000
Subject: [issue39397] Mac : fail to launch Python 3.8
In-Reply-To: <1579535856.72.0.329847745345.issue39397@roundup.psfhosted.org>
Message-ID: <1579683871.95.0.415915090951.issue39397@roundup.psfhosted.org>


Sebastien Foo <sgandon at gmail.com> added the comment:

Thanks a lot for you help, my issue is solved.
My ~/.zshrc was having a LANG env var set to
     
LANG=en_US

I just commented out this line and everything works fine.
I don't know why this was set like that.

Thanks again for your time you can close this ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39397>
_______________________________________

From report at bugs.python.org  Wed Jan 22 04:32:01 2020
From: report at bugs.python.org (Angel Cervera Claudio)
Date: Wed, 22 Jan 2020 09:32:01 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
Message-ID: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>


New submission from Angel Cervera Claudio <angelcervera at silyan.com>:

The link "See also: Python Packaging User Guide: Creating and using virtual environments" Is broken.

The problem is in line 30 of https://github.com/python/cpython/blob/3.8/Doc/library/venv.rst

I don't know the right link, so I can not fix it.

I any one provive me the right link, I can create a PR.

----------
assignee: docs at python
components: Documentation
messages: 360454
nosy: angelcervera, docs at python
priority: normal
severity: normal
status: open
title: Link to "Python Packaging User Guide: Creating and using virtual environments" is broken
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Wed Jan 22 04:35:38 2020
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 22 Jan 2020 09:35:38 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>
Message-ID: <1579685738.22.0.155816452927.issue39417@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Hi Angel, thank you for the report! The file that corresponds to that documentation is here https://github.com/python/cpython/blob/master/Doc/library/venv.rst and we'd be happy to have you make a PR for it :)

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Wed Jan 22 04:37:42 2020
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 22 Jan 2020 09:37:42 +0000
Subject: [issue39417] Link to "Python Packaging User Guide: Creating and using
 virtual environments" is broken
In-Reply-To: <1579685521.64.0.0587075259852.issue39417@roundup.psfhosted.org>
Message-ID: <1579685862.8.0.777187350129.issue39417@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Oh and I think the new link should point here: https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/#creating-a-virtual-environment

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39417>
_______________________________________

From report at bugs.python.org  Wed Jan 22 05:01:48 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 22 Jan 2020 10:01:48 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579687308.36.0.669507107593.issue39377@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 5bbac8cbdf140ebce446ea4e7db2b20a5d7b8402 by Inada Naoki in branch 'master':
bpo-39377: json: Update doc about the encoding option. (GH-18076)
https://github.com/python/cpython/commit/5bbac8cbdf140ebce446ea4e7db2b20a5d7b8402


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Wed Jan 22 05:22:24 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 22 Jan 2020 10:22:24 +0000
Subject: [issue39377] json.loads encoding parameter deprecation removal in
 Python 3.9
In-Reply-To: <1579325260.22.0.801200056997.issue39377@roundup.psfhosted.org>
Message-ID: <1579688544.15.0.786779009312.issue39377@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39377>
_______________________________________

From report at bugs.python.org  Wed Jan 22 06:56:40 2020
From: report at bugs.python.org (Batuhan)
Date: Wed, 22 Jan 2020 11:56:40 +0000
Subject: [issue39411] pyclbr rewrite using AST
In-Reply-To: <1579613369.33.0.216761296366.issue39411@roundup.psfhosted.org>
Message-ID: <1579694200.6.0.781234708535.issue39411@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Thanks for the suggestions Terry, I didn't want to change any behavior or make any feature addition (except is_async as stated in issue description) in this PR. 

> The change is needed 2 other places.  Could be part of this PR or another one.

I have a friend who would like to make his first contribution, so if it is not going to be problem, he'll take care of class browser references.

> Possible API changes based on IDLE module browser experience

Yes, it would be way better use tree/node structre instead of returning raw dictionaries. I can draft something after PR 1803 is merged. 

I dont have much experience of IDLE's architecture, but I can try to help if you want on the 4th point. 


Another thing I was considering is deprecating `readmodule` function, as you stated it is now module browser not class browser and `readmodule_ex` is sufficient. I dont know if any core developer will sponsor this idea, but I think `readmodule` should die. Thanks again for the suggestions and PR reviews.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39411>
_______________________________________

From report at bugs.python.org  Wed Jan 22 07:16:56 2020
From: report at bugs.python.org (Natalie Amery)
Date: Wed, 22 Jan 2020 12:16:56 +0000
Subject: [issue39418] str.strip() should have a means of adding to the default
 behaviour
Message-ID: <1579695416.2.0.0994259543651.issue39418@roundup.psfhosted.org>


New submission from Natalie Amery <phqcjz at fyvzl.net>:

If I want to remove the default set of 'whitespace' characters plus something else from a string there's currently no way to cleanly specify that.  In addition there's no way to programatically acquire what characters are considered whitespace so you can't call split with an argument constructed of existing whitespace characters with the new things you need.

As an example you could have an additionally= parameter such that:

"   ( 123 )   ".strip() gives "( 123 )" and
"   ( 123 )   ".strip(additionally="()") gives "123"

I've not given that any thought so it's probably not the best way of solving the problem.

----------
messages: 360459
nosy: senji
priority: normal
severity: normal
status: open
title: str.strip() should have a means of adding to the default behaviour
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39418>
_______________________________________

From report at bugs.python.org  Wed Jan 22 07:23:14 2020
From: report at bugs.python.org (Natalie Amery)
Date: Wed, 22 Jan 2020 12:23:14 +0000
Subject: [issue39418] str.strip() should have a means of adding to the default
 behaviour
In-Reply-To: <1579695416.2.0.0994259543651.issue39418@roundup.psfhosted.org>
Message-ID: <1579695794.16.0.24380751229.issue39418@roundup.psfhosted.org>


Natalie Amery <phqcjz at fyvzl.net> added the comment:

Oops, sorry, that should say 'strip' througout not 'split'.  My bad.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39418>
_______________________________________

From report at bugs.python.org  Wed Jan 22 07:29:39 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 22 Jan 2020 12:29:39 +0000
Subject: [issue39418] str.strip() should have a means of adding to the default
 behaviour
In-Reply-To: <1579695416.2.0.0994259543651.issue39418@roundup.psfhosted.org>
Message-ID: <1579696179.85.0.379932594591.issue39418@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

This is a new feature, not a bug, so it will apply only to 3.9. All older versions are in feature freeze.

> there's no way to programatically acquire what characters are considered whitespace

https://docs.python.org/3/library/stdtypes.html#str.isspace

https://docs.python.org/3/library/string.html#string.whitespace

----------
nosy: +steven.daprano
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39418>
_______________________________________

From report at bugs.python.org  Wed Jan 22 07:46:34 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 22 Jan 2020 12:46:34 +0000
Subject: [issue39397] Mac : fail to launch Python 3.8
In-Reply-To: <1579535856.72.0.329847745345.issue39397@roundup.psfhosted.org>
Message-ID: <1579697194.8.0.0413713370621.issue39397@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39397>
_______________________________________

From report at bugs.python.org  Wed Jan 22 07:50:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 12:50:46 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579697446.53.0.696640102383.issue39413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset f84f65be5602e561fef04b66bb487fbc4e560db5 by Victor Stinner in branch '3.8':
bpo-39413: os.unsetenv() is not available on Windows (GH-18108)
https://github.com/python/cpython/commit/f84f65be5602e561fef04b66bb487fbc4e560db5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Wed Jan 22 07:51:13 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Jan 2020 12:51:13 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579697473.35.0.446431388386.issue39413@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17501
pull_request: https://github.com/python/cpython/pull/18114

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Wed Jan 22 07:56:26 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Jan 2020 12:56:26 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579697786.66.0.222936120428.issue39413@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 570724667d37fcb160cdef2b34190dc36e28155c by Miss Islington (bot) in branch '3.7':
bpo-39413: os.unsetenv() is not available on Windows (GH-18108)
https://github.com/python/cpython/commit/570724667d37fcb160cdef2b34190dc36e28155c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Wed Jan 22 08:07:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 13:07:13 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579698433.79.0.228068151142.issue39413@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17502
pull_request: https://github.com/python/cpython/pull/18115

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Wed Jan 22 08:14:03 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 22 Jan 2020 13:14:03 +0000
Subject: [issue39418] str.strip() should have a means of adding to the default
 behaviour
In-Reply-To: <1579695416.2.0.0994259543651.issue39418@roundup.psfhosted.org>
Message-ID: <1579698843.96.0.286836828974.issue39418@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

There's a discrepancy between the string.whitespace constant and actual whitespace as tested by the str.isspace() method.

I've found five ASCII whitespace characters (as reported by isspace) which aren't in the string.whitespace constant, and 18 non-ASCII whitespace characters which aren't in the string.

The good news is that there are no non-whitespace characters in the constant :-)

The non-ASCII ones probably don't matter, as string.whitespace is documented as only being ASCII. But the following are missing:

U+001C, U+001D, U+001E, U+001F, U+0085

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39418>
_______________________________________

From report at bugs.python.org  Wed Jan 22 08:20:31 2020
From: report at bugs.python.org (Karl O. Pinc)
Date: Wed, 22 Jan 2020 13:20:31 +0000
Subject: [issue39416] Document default numeric string formats
In-Reply-To: <1579673381.27.0.219895994404.issue39416@roundup.psfhosted.org>
Message-ID: <20200122072024.4ce0f923@slate.karlpinc.com>


Karl O. Pinc <kop at karlpinc.com> added the comment:

On Wed, 22 Jan 2020 06:09:41 +0000
"Eric V. Smith" <report at bugs.python.org> wrote:

> Eric V. Smith <eric at trueblade.com> added the comment:
> 
> Is the lack of this documentation causing some confusion somewhere?
> This isn't rhetorical, I'm genuinely curious what problem you're
> trying to solve.

I'd say no, there's no real confusion anywhere.

This started with a search for documentation on Python's
default string representation for float.  This accidentally
wound up on the python-dev mailing list and became a
more general discussion during which I suggested that
some fundamentals are clear.  This is pretty much just
a follow-up to that discussion.

> Is there any mainstream programming language where the basics of what
> you've laid out aren't true? It all seems pretty obvious to me. For
> example, I can't see anyone looking at this and saying "Ah, base 10.
> That's why it's producing the output I'm seeing."

Well, I just got done looking at YAML which has a lot of base-related
syntax including base 60.  :)

The problem that would be solved is that it's easy to rely
on the default Numeric output formats.  Most output probably
does not go through a formatter, although this may change
now that f-strings are so easy.  Anyway, this would guarantee
"normal output" for numbers, even when switching between
Python implementations.

Likewise, immutability of value when round-tripping through a
string is also obvious.  But is still an important property.

So if these properties are important then include them in the spec.
That's what specs are for.  (I could probably find some non-mainstream
languages (scheme perhaps) that have specs which include
similar documentation.  You pretty have to have a formatter
in compiled languages, so those won't specify a default.
Anyway, it shouldn't matter what other language specs do.)

I understand if nobody sees this as a real problem.  And
I don't want to stand up as a big proponent.  I'll
point out the argument here and let others decide.

Regards,

Karl <kop at karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39416>
_______________________________________

From report at bugs.python.org  Wed Jan 22 08:28:34 2020
From: report at bugs.python.org (Natalie Amery)
Date: Wed, 22 Jan 2020 13:28:34 +0000
Subject: [issue39418] str.strip() should have a means of adding to the default
 behaviour
In-Reply-To: <1579695416.2.0.0994259543651.issue39418@roundup.psfhosted.org>
Message-ID: <1579699714.16.0.646290491826.issue39418@roundup.psfhosted.org>


Natalie Amery <phqcjz at fyvzl.net> added the comment:

https://bugs.python.org/issue25433 has a summary of the issue about what actually constitutes whitespace from the perspective of improving the documentation. In terms of what strip does it turns out that string.whitespace is a red herring.

A list of whitespace characters _could_ be produced at runtime using str.isspace() but that would require iterating over the entire space of characters; which is likely to be slow as well as poor style.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39418>
_______________________________________

From report at bugs.python.org  Wed Jan 22 08:50:08 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 22 Jan 2020 13:50:08 +0000
Subject: [issue39418] str.strip() should have a means of adding to the default
 behaviour
In-Reply-To: <1579695416.2.0.0994259543651.issue39418@roundup.psfhosted.org>
Message-ID: <1579701008.21.0.670113404564.issue39418@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Attached is a script I used to test:

* that str.isspace() currently matches the definition given in the docs;

* that string.whitespace contains all whitespace characters, and nothing but whitespace;

* that str.strip() strips off all whitespace characters, and nothing but whitespace;

* that str.split() splits on all whitespace characters, and nothing but whitespace.

I haven't tested the .lstrip rstrip rsplit methods because I'm lazy :-)

The only test that fails is that the string.whitespace is missing some whitespace.

Again, because I'm lazy, I haven't written this as proper unit tests. Besides, it's quite likely all these things are already in the official test suite. (If not, I might re-write the missing parts as unit tests and submit a PR.)

----------
Added file: https://bugs.python.org/file48858/test_ws.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39418>
_______________________________________

From report at bugs.python.org  Wed Jan 22 09:08:46 2020
From: report at bugs.python.org (Erik Aronesty)
Date: Wed, 22 Jan 2020 14:08:46 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1579702126.75.0.755894710326.issue35003@roundup.psfhosted.org>


Erik Aronesty <erik at q32.com> added the comment:

> The Scripts/bin thing is not specific to venv - for whatever reason, the original Windows implementation chose to use "Scripts" rather than "bin" 

That's irrelevant to the PR, which solves the problem in a compatible way.   There's no compatibility issues if a link is made to the activate script, rather than moving the directory at all.

> My guess is you would need to propose a PEP to move *everything* over from "Scripts" to "bin" in the Windows Python world

Certainly not.  That would break everything and would be a bad idea.

> This issue was already rejected before you added your PR so I'm not sure why you went to the trouble of creating a PR.

Because the issue was rejected due to come conflating logic and confusion as to what the underlying problem and issue is.

The venv system produces files specifically for activation on Windows which must and should reside in the Scripts directory.

The venv system also produces files for activation in a bash (or similar) shell.  This *should* reside in the bin directory (there is no o/s dependency here), and it should *also* reside in the Scripts directory ... for compatibility.

Expressed that way, it's clear what the solution is.   Hence the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Wed Jan 22 09:11:07 2020
From: report at bugs.python.org (Gerrit Holl)
Date: Wed, 22 Jan 2020 14:11:07 +0000
Subject: [issue39419] Core dump when trying to use workaround for custom
 warning category (Fatal Python error: init_sys_streams: can't initialize sys
 standard streams)
Message-ID: <1579702267.6.0.24270262544.issue39419@roundup.psfhosted.org>


New submission from Gerrit Holl <gerrit.holl at gmail.com>:

Pythons commandline warning filter cannot currently handle custom warning categories.  See https://bugs.python.org/issue22543

I tried a workaround as suggested on Stack Overflow <https://stackoverflow.com/a/53538033/974555> to filter on a warning category defined in pandas.errors.__init__.py (DtypeWarning):

PYTHONPATH=/media/nas/x21324/miniconda3/envs/py37e/lib/python3.7/site-packages/pandas/ python -Werror::errors.DtypeWarning

However, this results in a Fatal Python error and core dump:

Fatal Python error: init_sys_streams: can't initialize sys standard streams
AttributeError: module 'io' has no attribute 'OpenWrapper'

Current thread 0x00007f7bb3be76c0 (most recent call first):
Aborted (core dumped)

----------
messages: 360469
nosy: Gerrit.Holl
priority: normal
severity: normal
status: open
title: Core dump when trying to use workaround for custom warning category (Fatal Python error: init_sys_streams: can't initialize sys standard streams)
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39419>
_______________________________________

From report at bugs.python.org  Wed Jan 22 09:36:43 2020
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jan 2020 14:36:43 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
In-Reply-To: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>
Message-ID: <1579703803.8.0.312891131715.issue39082@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +17503
pull_request: https://github.com/python/cpython/pull/18116

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Wed Jan 22 09:39:26 2020
From: report at bugs.python.org (Matt Kokotovich)
Date: Wed, 22 Jan 2020 14:39:26 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
In-Reply-To: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>
Message-ID: <1579703966.03.0.342167771907.issue39082@roundup.psfhosted.org>


Matt Kokotovich <mkokotovich at gmail.com> added the comment:

I'd love to see this issue resolved, as it is keeping me from being able to switch to 3.8. 

I have a PR with Karthikeyan's suggestion, as I agree it makes more sense and could apply to more cases: https://github.com/python/cpython/pull/18116

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Wed Jan 22 09:55:43 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Jan 2020 14:55:43 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579704943.8.0.865953162738.issue39395@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
type:  -> crash
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Wed Jan 22 09:57:43 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Jan 2020 14:57:43 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579705063.96.0.548269703992.issue39395@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Issue39406 is a new feature. In any case we should fix potential crash in older Python versions.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:00:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 15:00:03 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579705203.27.0.195797845327.issue39395@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Issue39406 is a new feature. In any case we should fix potential crash in older Python versions.

Python 3.8 and older are not affected by this issue since they never destroy the posix_putenv_garbage dictionary: memory is never released.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:00:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 15:00:11 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579705211.38.0.0615252551781.issue39395@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:10:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 15:10:19 +0000
Subject: [issue39420] Windows: convertenviron() doesn't parse environment
 variables properly
Message-ID: <1579705819.39.0.675106611885.issue39420@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

os.environ is created by convertenviron() of posixmodule.c. The Windows implementation calls _wgetenv(L"") to initialize _wenviron, and then parses the _wenviron string.

The _wenviron string is parsed by search for the first "=" character to split between the variable name and the variable value. For example, "USER=vstinner" is parsed as name="USER" and value="vstinner".

The problem is that the _wputenv() function allows to insert variable names containing the "=" character (but reject names starting with "=" character). Python can inherit an environment with a name containing "=".

One solution can be to use GetEnvironmentStringsW() which uses null characters to separate variable name and variable value. It returns a string like "name1\0value1\0name2\0value2\0\0": the string ends with a null character as well, to mark the end of the list.

https://docs.microsoft.com/en-us/windows/win32/api/processenv/nf-processenv-getenvironmentstrings?redirectedfrom=MSDN

Python 3.8 *explicitly* rejects variable names containing "=", at least on Windows, likely to workaround this issue. But another program can inject such variable in the environment.

Example with a Python modified to not reject explicitly "=" in the varaible name:
---
import subprocess, os, sys
os.putenv("victor=", "secret")
code = """import os; print(f"victor: {os.getenv('victor')!r}"); print(f"victor=: {os.getenv('victor=')!r}")"""
subprocess.run([sys.executable, "-c", code])
---

Output:
---
victor: '=secret'
victor=: None
---

Expected output:
---
victor: None
victor=: '=secret'
---

----------
components: Library (Lib)
messages: 360473
nosy: vstinner
priority: normal
severity: normal
status: open
title: Windows: convertenviron() doesn't parse environment variables properly
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39420>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:11:46 2020
From: report at bugs.python.org (Dk0n9)
Date: Wed, 22 Jan 2020 15:11:46 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
Message-ID: <1579705906.5.0.185144914651.issue39421@roundup.psfhosted.org>


Change by Dk0n9 <ph4nt0merd at gmail.com>:


----------
components: Extension Modules
nosy: dk0n9
priority: normal
severity: normal
status: open
title: Use-after-free in heappushpop() of heapq module
type: crash
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:13:43 2020
From: report at bugs.python.org (Dk0n9)
Date: Wed, 22 Jan 2020 15:13:43 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
Message-ID: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>


New submission from Dk0n9 <ph4nt0merd at gmail.com>:

The variable `heap` in heappushpop does not add a reference count

```c
    cmp = PyObject_RichCompareBool(PyList_GET_ITEM(heap, 0), item, Py_LT);
    if (cmp < 0)
        return NULL;
    if (cmp == 0) {
        Py_INCREF(item);
        return item;
    }
```

POC?
```python
import heapq

class h(int):
    def __lt__(self, o):
        list1.clear()
        return NotImplemented

list1 = []

heapq.heappush(list1, h(0))
heapq.heappushpop(list1, 1)
```


Crash detail with asan:

==62141==ERROR: AddressSanitizer: heap-use-after-free on address 0x6060000fd778 at pc 0x00000049cdce bp 0x7ffe9690f650 sp 0x7ffe9690f640
READ of size 8 at 0x6060000fd778 thread T0
    #0 0x49cdcd in long_richcompare Objects/longobject.c:3047
    #1 0x4f9495 in do_richcompare Objects/object.c:802
    #2 0x4f9495 in PyObject_RichCompare Objects/object.c:846
    #3 0x4f9495 in PyObject_RichCompareBool Objects/object.c:868
    #4 0x7ff74c523594 in _heapq_heappushpop_impl /home/******/Python-3.9.0a2/Modules/_heapqmodule.c:267
    #5 0x7ff74c523594 in _heapq_heappushpop /home/******/Python-3.9.0a2/Modules/clinic/_heapqmodule.c.h:109
    #6 0x854c30 in cfunction_vectorcall_FASTCALL Objects/methodobject.c:366
    #7 0x443885 in _PyObject_VectorcallTstate Include/cpython/abstract.h:111
    #8 0x443885 in _PyObject_Vectorcall Include/cpython/abstract.h:120
    #9 0x443885 in call_function Python/ceval.c:4850
    #10 0x443885 in _PyEval_EvalFrameDefault Python/ceval.c:3306
    #11 0x5e1d76 in _PyEval_EvalFrame Include/internal/pycore_ceval.h:43
    #12 0x5e1d76 in _PyEval_EvalCode Python/ceval.c:4142
    #13 0x5e2207 in _PyEval_EvalCodeWithName Python/ceval.c:4174
    #14 0x5e2207 in PyEval_EvalCodeEx Python/ceval.c:4190
    #15 0x5e2207 in PyEval_EvalCode Python/ceval.c:717
    #16 0x6862fc in run_eval_code_obj Python/pythonrun.c:1125
    #17 0x6862fc in run_mod Python/pythonrun.c:1147
    #18 0x6862fc in PyRun_FileExFlags Python/pythonrun.c:1063
    #19 0x6867b2 in PyRun_SimpleFileExFlags Python/pythonrun.c:428
    #20 0x446495 in pymain_run_file Modules/main.c:369
    #21 0x446495 in pymain_run_python Modules/main.c:553
    #22 0x446495 in Py_RunMain Modules/main.c:632
    #23 0x446f86 in pymain_main Modules/main.c:662
    #24 0x446f86 in Py_BytesMain Modules/main.c:686
    #25 0x7ff74f34882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #26 0x444478 in _start (/home/***/Python-3.9.0a2/python+0x444478)

0x6060000fd778 is located 24 bytes inside of 56-byte region [0x6060000fd760,0x6060000fd798)
freed by thread T0 here:
    #0 0x7ff7500b72ca in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x982ca)
    #1 0x52a5d9 in subtype_dealloc Objects/typeobject.c:1291
    #2 0x4222a6 in _Py_DECREF Include/object.h:478
    #3 0x4222a6 in frame_dealloc Objects/frameobject.c:636
    #4 0x422088 in _Py_DECREF Include/object.h:478
    #5 0x422088 in function_code_fastcall Objects/call.c:335
    #6 0x53aac6 in _PyObject_VectorcallTstate Include/cpython/abstract.h:111
    #7 0x53aac6 in vectorcall_unbound Objects/typeobject.c:1459
    #8 0x53aac6 in slot_tp_richcompare Objects/typeobject.c:6703
    #9 0x4f921d in do_richcompare Objects/object.c:796
    #10 0x4f921d in PyObject_RichCompare Objects/object.c:846
    #11 0x4f921d in PyObject_RichCompareBool Objects/object.c:868
    #12 0x7ff74c523594 in _heapq_heappushpop_impl /home/******/Python-3.9.0a2/Modules/_heapqmodule.c:267
    #13 0x7ff74c523594 in _heapq_heappushpop /home/******/Python-3.9.0a2/Modules/clinic/_heapqmodule.c.h:109
    #14 0x854c30 in cfunction_vectorcall_FASTCALL Objects/methodobject.c:366
    #15 0x443885 in _PyObject_VectorcallTstate Include/cpython/abstract.h:111
    #16 0x443885 in _PyObject_Vectorcall Include/cpython/abstract.h:120
    #17 0x443885 in call_function Python/ceval.c:4850
    #18 0x443885 in _PyEval_EvalFrameDefault Python/ceval.c:3306
    #19 0x5e1d76 in _PyEval_EvalFrame Include/internal/pycore_ceval.h:43
    #20 0x5e1d76 in _PyEval_EvalCode Python/ceval.c:4142
    #21 0x5e2207 in _PyEval_EvalCodeWithName Python/ceval.c:4174
    #22 0x5e2207 in PyEval_EvalCodeEx Python/ceval.c:4190
    #23 0x5e2207 in PyEval_EvalCode Python/ceval.c:717
    #24 0x6862fc in run_eval_code_obj Python/pythonrun.c:1125
    #25 0x6862fc in run_mod Python/pythonrun.c:1147
    #26 0x6862fc in PyRun_FileExFlags Python/pythonrun.c:1063
    #27 0x6867b2 in PyRun_SimpleFileExFlags Python/pythonrun.c:428
    #28 0x446495 in pymain_run_file Modules/main.c:369
    #29 0x446495 in pymain_run_python Modules/main.c:553
    #30 0x446495 in Py_RunMain Modules/main.c:632
    #31 0x446f86 in pymain_main Modules/main.c:662
    #32 0x446f86 in Py_BytesMain Modules/main.c:686
    #33 0x7ff74f34882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

previously allocated by thread T0 here:
    #0 0x7ff7500b7602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
    #1 0x6dbfd5 in _PyObject_GC_Alloc Modules/gcmodule.c:2146
    #2 0x6dbfd5 in _PyObject_GC_Malloc Modules/gcmodule.c:2173
    #3 0x527d20 in PyType_GenericAlloc Objects/typeobject.c:1014
    #4 0x4b890b in long_subtype_new Objects/longobject.c:5132
    #5 0x4b890b in long_new_impl Objects/longobject.c:5075
    #6 0x4b890b in long_new Objects/clinic/longobject.c.h:36
    #7 0x52f606 in type_call Objects/typeobject.c:973
    #8 0x462b46 in _PyObject_MakeTpCall Objects/call.c:189
    #9 0x436b70 in _PyObject_VectorcallTstate Include/cpython/abstract.h:109
    #10 0x436b70 in _PyObject_Vectorcall Include/cpython/abstract.h:120
    #11 0x436b70 in call_function Python/ceval.c:4850
    #12 0x436b70 in _PyEval_EvalFrameDefault Python/ceval.c:3337
    #13 0x5e1d76 in _PyEval_EvalFrame Include/internal/pycore_ceval.h:43
    #14 0x5e1d76 in _PyEval_EvalCode Python/ceval.c:4142
    #15 0x5e2207 in _PyEval_EvalCodeWithName Python/ceval.c:4174
    #16 0x5e2207 in PyEval_EvalCodeEx Python/ceval.c:4190
    #17 0x5e2207 in PyEval_EvalCode Python/ceval.c:717
    #18 0x6862fc in run_eval_code_obj Python/pythonrun.c:1125
    #19 0x6862fc in run_mod Python/pythonrun.c:1147
    #20 0x6862fc in PyRun_FileExFlags Python/pythonrun.c:1063
    #21 0x6867b2 in PyRun_SimpleFileExFlags Python/pythonrun.c:428
    #22 0x446495 in pymain_run_file Modules/main.c:369
    #23 0x446495 in pymain_run_python Modules/main.c:553
    #24 0x446495 in Py_RunMain Modules/main.c:632
    #25 0x446f86 in pymain_main Modules/main.c:662
    #26 0x446f86 in Py_BytesMain Modules/main.c:686
    #27 0x7ff74f34882f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

SUMMARY: AddressSanitizer: heap-use-after-free Objects/longobject.c:3047 long_richcompare
Shadow bytes around the buggy address:
  0x0c0c80017a90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017aa0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017ab0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017ac0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c0c80017ad0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x0c0c80017ae0: fd fd fd fd fd fd fd fa fa fa fa fa fd fd fd[fd]
  0x0c0c80017af0: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c80017b00: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa
  0x0c0c80017b10: 00 00 00 00 00 00 00 00 fa fa fa fa fd fd fd fd
  0x0c0c80017b20: fd fd fd fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x0c0c80017b30: fa fa fa fa fd fd fd fd fd fd fd fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
==62141==ABORTING

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:23:06 2020
From: report at bugs.python.org (Alex Rebert)
Date: Wed, 22 Jan 2020 15:23:06 +0000
Subject: [issue35182] Popen.communicate() breaks when child closes its side of
 pipe but not exits
In-Reply-To: <1541586210.62.0.788709270274.issue35182@psf.upfronthosting.co.za>
Message-ID: <1579706586.23.0.90312747968.issue35182@roundup.psfhosted.org>


Change by Alex Rebert <alexandre.rebert at gmail.com>:


----------
pull_requests: +17504
pull_request: https://github.com/python/cpython/pull/18117

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35182>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:31:24 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jan 2020 15:31:24 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579707084.09.0.22047047625.issue39421@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

Reproducible.

It looks similar to bpo-38588.
We will apply the same solution as we did at bpo-38588?
or do we plan to apply the solution which is suggested on msg359023?

----------
nosy: +corona10, inada.naoki, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:31:53 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jan 2020 15:31:53 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579707113.4.0.869501202859.issue39421@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
stage:  -> needs patch
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:32:01 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jan 2020 15:32:01 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579707121.07.0.310277588955.issue39421@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:37:38 2020
From: report at bugs.python.org (Manjusaka)
Date: Wed, 22 Jan 2020 15:37:38 +0000
Subject: [issue39408] Add support for SQLCipher
In-Reply-To: <1579599170.77.0.875579101001.issue39408@roundup.psfhosted.org>
Message-ID: <1579707458.79.0.937415251135.issue39408@roundup.psfhosted.org>


Manjusaka <lizheao940510 at gmail.com> added the comment:

To be serious, I don't think using SQLCipher is a good idea for CPython

Cause, SQLCipher is always released by the source code, not the binary. That means we should compile and manage the binary on different platforms, sush as ffi on windows, Openssl on Windows.


I think that will bring in some substantial compatibility problems.

I think the ROI is not enough to make this change.

----------
nosy: +Manjusaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39408>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:46:55 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Jan 2020 15:46:55 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579708015.65.0.295764806732.issue39421@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

To be honest, given how many ways this bug happens I think its time to consider msg359023.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:49:45 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jan 2020 15:49:45 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579708185.05.0.658807890962.issue39421@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> To be honest, given how many ways this bug happens I think its time to consider msg359023.

+1 to me also

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:54:31 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Jan 2020 15:54:31 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579708471.56.0.427793865759.issue39421@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +17505
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18118

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:55:25 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Jan 2020 15:55:25 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579708525.91.0.464019679001.issue39421@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

AS this discussion will take a while and likely will have deeper consequences, in the meantime I created PR18118 to specifically fix this.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Wed Jan 22 10:56:03 2020
From: report at bugs.python.org (Cleland Loszewski)
Date: Wed, 22 Jan 2020 15:56:03 +0000
Subject: [issue39422] datetime.datetime.strptime incorrectly interpretting
 format '%Y%m%d'
Message-ID: <1579708563.29.0.511970364899.issue39422@roundup.psfhosted.org>


New submission from Cleland Loszewski <losze1cj at gmail.com>:

```python
from datetime import datetime
print(datetime.strptime('2020016', '%Y%m%d'))
print(datetime.strptime('20200116', '%Y%m%d'))
```
The former string has a format that does not match '%Y%m%d', but the latter does.  Both report the same datatime output.

----------
components: Library (Lib)
messages: 360480
nosy: losze1cj
priority: normal
severity: normal
status: open
title: datetime.datetime.strptime incorrectly interpretting format '%Y%m%d'
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39422>
_______________________________________

From report at bugs.python.org  Wed Jan 22 11:05:55 2020
From: report at bugs.python.org (mapf)
Date: Wed, 22 Jan 2020 16:05:55 +0000
Subject: [issue39423] Process finished with exit code -1073741819 (0xC0000005)
 when trying to access data from a pickled file
Message-ID: <1579709155.26.0.28815846735.issue39423@roundup.psfhosted.org>


New submission from mapf <mapfus at gmx.de>:

I have a program where I create some relatively nested data and within the same session, I have no issues accessing the data. I then use picke.dump() with pickle.HIGHEST_PROTOCOL to save the data so I can access it in a later session.
These files are usually over 2GB large since they contain many images in the form of numpy arrays and I have never had any issues loading them. However there is one data structure that is a structured numpy array of type "a" with currently 16 different dtypes and they can all be accessed in the same session where they were created without any problems sometimes even after dumping and loading the data again. They can also all be accessed after they have been loaded in a different session with the exeption of one field.
This field contains rather nested data which is why I thought that this might be the issue, but I have honestly no idea. 
Each entry in this field is a list of len 20, whose entries are either None or a 1-d slice of "()"-shape from another structured array of type "b". This slice in turn has 37 different dtypes, most of which are either int, fload or bool. But there is one entry which is a list that can contain several dicts. The entries of this dict are floats, however one can be a slice of type "b" again, so there is some cross-referencing going on. As a test I already removed this entry though and it still crashed. 
My point is, the data that is stored is not of some crazy custom type. All the data is either of type bool, int, fload, list, dict or numpy.array. As I said, ALL the other stored data can be accessed without any problems. It is only this one field that can only be accessed during the same session it was created. 
My program runs using a PyQt5 GUI and I use PyCharm as the editor. I have already read that in the past, these two in combination seem to cause this error rather frequently maybe that has something to do with it. 
I have already tried reinstalling my Python distribution as well as PyCharm as well as running the code on a different machine to no avail. 
I am also pretty certain that this used to work just last week ago. I didn't change my code but now it doesn't work anymore.


Relevant specs:

Windows 10 Home 64 bit
PyCharm 2019.3.1 Professional
Python 3.7.4 via Anaconda
Numpy 1.16.5
PyQt 5.9.2

----------
messages: 360481
nosy: mapf
priority: normal
severity: normal
status: open
title: Process finished with exit code -1073741819 (0xC0000005) when trying to access data from a pickled file
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39423>
_______________________________________

From report at bugs.python.org  Wed Jan 22 11:07:23 2020
From: report at bugs.python.org (Manjusaka)
Date: Wed, 22 Jan 2020 16:07:23 +0000
Subject: [issue31405] shutil.which doesn't find files without PATHEXT
 extension on Windows
In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za>
Message-ID: <1579709243.41.0.151437729959.issue31405@roundup.psfhosted.org>


Manjusaka <lizheao940510 at gmail.com> added the comment:

Hello Anthony

would you mind to execute this command on your PC?

python -c "import os; print(os.environ.get("PATHEXT", "").split(os.pathsep))"

and show the result about this code?

----------
nosy: +Manjusaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31405>
_______________________________________

From report at bugs.python.org  Wed Jan 22 11:08:16 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 22 Jan 2020 16:08:16 +0000
Subject: [issue39422] datetime.datetime.strptime incorrectly interpretting
 format '%Y%m%d'
In-Reply-To: <1579708563.29.0.511970364899.issue39422@roundup.psfhosted.org>
Message-ID: <1579709296.75.0.531798501087.issue39422@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +belopolsky, p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39422>
_______________________________________

From report at bugs.python.org  Wed Jan 22 11:08:46 2020
From: report at bugs.python.org (mapf)
Date: Wed, 22 Jan 2020 16:08:46 +0000
Subject: [issue39423] Process finished with exit code -1073741819 (0xC0000005)
 when trying to access data from a pickled file
In-Reply-To: <1579709155.26.0.28815846735.issue39423@roundup.psfhosted.org>
Message-ID: <1579709326.07.0.106418312738.issue39423@roundup.psfhosted.org>


mapf <mapfus at gmx.de> added the comment:

I forgot to mention that sometimes, when I dump and load the data in the same session and try to access / use the data in question, I get the following Error:

"Fatal Python error: GC object already tracked"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39423>
_______________________________________

From report at bugs.python.org  Wed Jan 22 11:13:21 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jan 2020 16:13:21 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579709601.61.0.989734437167.issue39421@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@pablogsal

I agree with hotfix is needed and also for discussion.
I left a comment for PR 18118. Please take a look :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Wed Jan 22 11:30:36 2020
From: report at bugs.python.org (Anthony Sottile)
Date: Wed, 22 Jan 2020 16:30:36 +0000
Subject: [issue31405] shutil.which doesn't find files without PATHEXT
 extension on Windows
In-Reply-To: <1504980729.07.0.774720722316.issue31405@psf.upfronthosting.co.za>
Message-ID: <1579710636.28.0.734662340318.issue31405@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

sure, it's the standard PATHEXT (basically a fresh vm from modern.ie) -- the only reason I noticed this is I was reading the source: https://github.com/python/cpython/blob/5bbac8cbdf140ebce446ea4e7db2b20a5d7b8402/Lib/shutil.py#L1367-L1373



C:\Users\IEUser>echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY;.PYW

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31405>
_______________________________________

From report at bugs.python.org  Wed Jan 22 11:56:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 16:56:21 +0000
Subject: [issue39424] test_signal: test_pidfd_send_signal() uses deprecated
 assertRaisesRegexp() method
Message-ID: <1579712181.32.0.0974422649306.issue39424@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

test_signal.test_pidfd_send_signal() should use assertRaisesRegex() rather than assertRaisesRegexp():

$ ./python -Werror -m test -v test_signal -m test_pidfd_send_signal 
(...)
======================================================================
ERROR: test_pidfd_send_signal (test.test_signal.PidfdSignalTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/python/master/Lib/test/test_signal.py", line 1292, in test_pidfd_send_signal
    with self.assertRaisesRegexp(TypeError, "^siginfo must be None$"):
  File "/home/vstinner/python/master/Lib/unittest/case.py", line 1390, in deprecated_func
    warnings.warn(
DeprecationWarning: Please use assertRaisesRegex instead.

----------
components: Tests
keywords: newcomer friendly
messages: 360486
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_signal: test_pidfd_send_signal() uses deprecated assertRaisesRegexp() method
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39424>
_______________________________________

From report at bugs.python.org  Wed Jan 22 12:07:04 2020
From: report at bugs.python.org (SilentGhost)
Date: Wed, 22 Jan 2020 17:07:04 +0000
Subject: [issue39422] datetime.datetime.strptime incorrectly interpretting
 format '%Y%m%d'
In-Reply-To: <1579708563.29.0.511970364899.issue39422@roundup.psfhosted.org>
Message-ID: <1579712824.75.0.151792592005.issue39422@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

They do not "report same datetime output". Did you mean to use '20200106' as the second input string? Because, leading zeros being optional for certain format specifiers is a documented feature of strptime.

----------
nosy: +SilentGhost
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39422>
_______________________________________

From report at bugs.python.org  Wed Jan 22 12:16:03 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jan 2020 17:16:03 +0000
Subject: [issue39425] list.count performance regression
Message-ID: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

./python.exe -m pyperf timeit -s 'a = [1]*100'  'a.count(1)'

Current Master: Mean +- std dev: 1.05 us +- 0.03 us
My patch: Mean +- std dev: 423 ns +- 11 ns

This is the side-effect of pr 17022.

----------
assignee: corona10
messages: 360488
nosy: corona10
priority: normal
severity: normal
status: open
title: list.count performance regression
type: performance
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 12:17:30 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jan 2020 17:17:30 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579713450.64.0.0601183208471.issue39425@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +inada.naoki, pablogsal, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 12:17:47 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jan 2020 17:17:47 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579713467.34.0.192178285679.issue39425@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17506
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18119

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 12:23:06 2020
From: report at bugs.python.org (Julien Palard)
Date: Wed, 22 Jan 2020 17:23:06 +0000
Subject: [issue38495] print built-in function docs bug
In-Reply-To: <1571211401.15.0.283514863374.issue38495@roundup.psfhosted.org>
Message-ID: <1579713786.55.0.751345415418.issue38495@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

PR 17062 about stating it's a space by default has been rejected.

I also feel we should just enhance the space width in the prototype.

I personally see the space, but as it's in italic, I can understand it's very easy to miss it.

I like the `font-family: monospace, sans-serif; font-style: normal;` a lot, it make it clear, see screenshot, but it's an issue for python-docs-theme, opening it there: https://github.com/python/python-docs-theme/issues/42

----------
keywords: +easy -patch
nosy: +mdk
Added file: https://bugs.python.org/file48859/Screenshot_2020-01-22 Fonctions natives ? Documentation Python 3 8 1.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38495>
_______________________________________

From report at bugs.python.org  Wed Jan 22 12:28:39 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 22 Jan 2020 17:28:39 +0000
Subject: [issue39420] Windows: convertenviron() doesn't parse environment
 variables properly
In-Reply-To: <1579705819.39.0.675106611885.issue39420@roundup.psfhosted.org>
Message-ID: <1579714119.55.0.232410001115.issue39420@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> The problem is that the _wputenv() function allows to insert variable 
> names containing the "=" character 

No, it does not. Your experiments uncovered bugs elsewhere with the implementations of _wgetenv and WINAPI GetEnvironmentVariableW, but this isn't one of them. _wputenv(L"victor==secret") updates the OS environment by calling SetEnvironmentVariableW(L"victor", L"=secret"). That is the only correct result. A variable name is only allowed to contain "=" as the first character, where it is unambiguous. The first "=" beyond the first character must be the value delimiter.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39420>
_______________________________________

From report at bugs.python.org  Wed Jan 22 12:35:01 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 22 Jan 2020 17:35:01 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579714501.55.0.488097391485.issue39425@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 12:36:57 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Jan 2020 17:36:57 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579714617.97.0.433567859246.issue39425@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 14d80d0b605d8b148e14458e4c1853a940071462 by Miss Islington (bot) (Dong-hee Na) in branch 'master':
bpo-39425: Fix list.count performance regression (GH-18119)
https://github.com/python/cpython/commit/14d80d0b605d8b148e14458e4c1853a940071462


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 12:37:18 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Jan 2020 17:37:18 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579714638.85.0.299175044782.issue39425@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17507
pull_request: https://github.com/python/cpython/pull/18120

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 12:37:28 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 22 Jan 2020 17:37:28 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579714648.2.0.399427067837.issue39425@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17508
pull_request: https://github.com/python/cpython/pull/18121

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 12:38:27 2020
From: report at bugs.python.org (Manuel Barkhau)
Date: Wed, 22 Jan 2020 17:38:27 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579714707.19.0.505478309654.issue39390@roundup.psfhosted.org>


Change by Manuel Barkhau <mbarkhau at gmail.com>:


----------
pull_requests: +17509
pull_request: https://github.com/python/cpython/pull/18122

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Wed Jan 22 13:10:25 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Jan 2020 18:10:25 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1579716625.87.0.181803151025.issue35003@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Wed Jan 22 13:11:25 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Jan 2020 18:11:25 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579716685.9.0.731648930463.issue39425@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset fdb21609d944941f0732df72dc3d07a7a9a7efea by Pablo Galindo (Miss Islington (bot)) in branch '3.8':
bpo-39425: Fix list.count performance regression (GH-18119) (GH-18120)
https://github.com/python/cpython/commit/fdb21609d944941f0732df72dc3d07a7a9a7efea


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 13:11:35 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Jan 2020 18:11:35 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579716695.24.0.395872776968.issue39425@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 9e06d61af30bac4fcacb7973f826147ccc010392 by Pablo Galindo (Miss Islington (bot)) in branch '3.7':
bpo-39425: Fix list.count performance regression (GH-18119) (GH-18121)
https://github.com/python/cpython/commit/9e06d61af30bac4fcacb7973f826147ccc010392


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 13:11:58 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Jan 2020 18:11:58 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579716718.9.0.160742890445.issue39425@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks for the PR, Dong-hee Na :)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 13:20:34 2020
From: report at bugs.python.org (Cleland Loszewski)
Date: Wed, 22 Jan 2020 18:20:34 +0000
Subject: [issue39422] datetime.datetime.strptime incorrectly interpretting
 format '%Y%m%d'
In-Reply-To: <1579708563.29.0.511970364899.issue39422@roundup.psfhosted.org>
Message-ID: <1579717234.2.0.401669297869.issue39422@roundup.psfhosted.org>


Cleland Loszewski <losze1cj at gmail.com> added the comment:

You're right, I did mean the second string to report '20200106'.  
Looking closer, I see that I was reading the documentation incorrectly and getting hung up on an introduced ambiguity.
```python
from datetime import datetime
print(datetime.strptime('2020016', '%Y%m%d'))
print(datetime.strptime('20200106', '%Y%m%d'))
print(datetime.strptime('202016', '%Y%m%d'))
print(datetime.strptime('2020106', '%Y%m%d'))
```

----------
resolution:  -> not a bug
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39422>
_______________________________________

From report at bugs.python.org  Wed Jan 22 13:36:49 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Jan 2020 18:36:49 +0000
Subject: [issue37444] Differing exception between builtins and importlib when
 importing beyond top-level package
In-Reply-To: <1561749733.32.0.955430999512.issue37444@roundup.psfhosted.org>
Message-ID: <1579718209.51.0.559655788304.issue37444@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

The problem with the hybrid exception is that importlib would then still raise a different exception from import itself, so the discrepancy would persist. And if you updated import you could then break people in another way where they were catching ValueError and ImportError separately for different cases and now they would potentially catch the wrong exception for that ValueError case.

Basically changing what exceptions get raised sucks as someone is almost inevitably broken. But since import and importlib strive to mirror each other as much as possible and be drop-in replacements, the consistency for the next 30 years of Python's life is more important I think than the case of:

1. Someone using importlib.import_module()
2. Who is specifically worried about relative imports going too far and no other import-related import and thus only catching ValueError and not ImportError
3. And are supporting older versions of Python
4. And will have a difficult time updating their `except` clause to now also capture ImportError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37444>
_______________________________________

From report at bugs.python.org  Wed Jan 22 13:40:02 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Jan 2020 18:40:02 +0000
Subject: [issue39426] Pickler docstring misstates default and highest protocols
Message-ID: <1579718401.91.0.32620424207.issue39426@roundup.psfhosted.org>


New submission from Mark Dickinson <dickinsm at gmail.com>:

>From the pickle.Pickler docstring:

> The optional *protocol* argument tells the pickler to use the given
> protocol; supported protocols are 0, 1, 2, 3 and 4.  The default
> protocol is 3; a backward-incompatible protocol designed for Python 3.

That's out of date since Python 3.8, where the default protocol is 4 and the highest available is 5. For future-proofing, it may be worth rewording the docstring to refer directly to the DEFAULT_PROTOCOL and HIGHEST_PROTOCOL constants.

----------
assignee: docs at python
components: Documentation
messages: 360497
nosy: docs at python, mark.dickinson, pitrou
priority: normal
severity: normal
status: open
title: Pickler docstring misstates default and highest protocols
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39426>
_______________________________________

From report at bugs.python.org  Wed Jan 22 13:42:40 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 22 Jan 2020 18:42:40 +0000
Subject: [issue39426] Pickler docstring misstates default and highest protocols
In-Reply-To: <1579718401.91.0.32620424207.issue39426@roundup.psfhosted.org>
Message-ID: <1579718560.47.0.559443316738.issue39426@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Good catch.  Do you want to submit a PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39426>
_______________________________________

From report at bugs.python.org  Wed Jan 22 13:57:28 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Jan 2020 18:57:28 +0000
Subject: [issue39426] Pickler docstring misstates default and highest protocols
In-Reply-To: <1579718401.91.0.32620424207.issue39426@roundup.psfhosted.org>
Message-ID: <1579719448.08.0.915766786143.issue39426@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Do you want to submit a PR?

Not immediately. I'll add it to my to-do list, but definitely won't complain if someone else gets there first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39426>
_______________________________________

From report at bugs.python.org  Wed Jan 22 13:57:51 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 22 Jan 2020 18:57:51 +0000
Subject: [issue39426] Pickler docstring misstates default and highest protocols
In-Reply-To: <1579718401.91.0.32620424207.issue39426@roundup.psfhosted.org>
Message-ID: <1579719471.62.0.148561402346.issue39426@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: docs at python -> mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39426>
_______________________________________

From report at bugs.python.org  Wed Jan 22 14:21:38 2020
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 22 Jan 2020 19:21:38 +0000
Subject: [issue39400] pydoc: Use of MANPAGER variable is incorrect
In-Reply-To: <1579554143.61.0.454786328579.issue39400@roundup.psfhosted.org>
Message-ID: <1579720898.51.0.164035697547.issue39400@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17510
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18123

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39400>
_______________________________________

From report at bugs.python.org  Wed Jan 22 14:29:56 2020
From: report at bugs.python.org (Dino Viehland)
Date: Wed, 22 Jan 2020 19:29:56 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579721396.43.0.398159629033.issue38076@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

With either fix, or with both, on Linux I still see this hang at shutdown.  Victor mentioned the fact that he had to hit Ctrl-C on Linux to see this, and I have to do the same thing. Then with the fixes in place the original test case still hangs on shutdown.  

On Python 3.7 (I don't readily have 3.8 available) at least this just runs and completes with no ctrl-C and no crashes.  So while either of the fixes may be good to prevent the crashes, there's still probably some underlying issue in multiprocessing.  I haven't tested on Mac OS/X.

It looks like the clearing was originally introduced here: https://bugs.python.org/issue10241  Interestingly there was a similar issue w/ _tkinter, which also used PyType_FromSpec (although it sounds like it was just a ref count issue on the type).  Unfortunately there's no associated test cases added to verify the behavior.  Antoine and Neil are both now on the PR which removes the collection behavior so hopefully they can chime in on the safety of that fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Wed Jan 22 14:44:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 19:44:25 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579722265.96.0.320403837385.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset beea26b57e8c80f1eff0f967a0f9d083a7dc3d66 by Victor Stinner in branch 'master':
bpo-39353: Deprecate the binhex module (GH-18025)
https://github.com/python/cpython/commit/beea26b57e8c80f1eff0f967a0f9d083a7dc3d66


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Wed Jan 22 14:45:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 19:45:46 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579722346.63.0.283693702579.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I agree with deprecating binhex.

Good :-) It's now deprecated.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Wed Jan 22 14:50:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 19:50:21 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579722621.48.0.60891233521.issue39413@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17511
pull_request: https://github.com/python/cpython/pull/18124

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Wed Jan 22 15:08:12 2020
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 22 Jan 2020 20:08:12 +0000
Subject: [issue39361] [C API] Document PyTypeObject.tp_print removal in What's
 New In Python 3.9
In-Reply-To: <1579182449.25.0.646688097362.issue39361@roundup.psfhosted.org>
Message-ID: <1579723692.68.0.53097552797.issue39361@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
pull_requests: +17512
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39361>
_______________________________________

From report at bugs.python.org  Wed Jan 22 15:11:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 20:11:20 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579723880.69.0.895285223414.issue39413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b73dd02ea744288831f71363a7467552c09875ea by Victor Stinner in branch 'master':
Revert "bpo-39413: Implement os.unsetenv() on Windows (GH-18104)" (GH-18124)
https://github.com/python/cpython/commit/b73dd02ea744288831f71363a7467552c09875ea


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Wed Jan 22 15:14:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 20:14:33 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579724073.72.0.406087509758.issue39406@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17513
pull_request: https://github.com/python/cpython/pull/18126

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Wed Jan 22 15:21:09 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 22 Jan 2020 20:21:09 +0000
Subject: [issue24337] Implement `http.client.HTTPMessage.__repr__` to make
 debugging easier
In-Reply-To: <1433071409.14.0.465304271938.issue24337@psf.upfronthosting.co.za>
Message-ID: <1579724469.89.0.561088681909.issue24337@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +17514
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18127

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24337>
_______________________________________

From report at bugs.python.org  Wed Jan 22 15:22:35 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 22 Jan 2020 20:22:35 +0000
Subject: [issue24337] Implement `http.client.HTTPMessage.__repr__` to make
 debugging easier
In-Reply-To: <1433071409.14.0.465304271938.issue24337@psf.upfronthosting.co.za>
Message-ID: <1579724555.5.0.25603017879.issue24337@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
versions: +Python 3.9 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24337>
_______________________________________

From report at bugs.python.org  Wed Jan 22 15:49:24 2020
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jan 2020 20:49:24 +0000
Subject: [issue24337] Implement `http.client.HTTPMessage.__repr__` to make
 debugging easier
In-Reply-To: <1433071409.14.0.465304271938.issue24337@psf.upfronthosting.co.za>
Message-ID: <1579726164.32.0.217434961276.issue24337@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the PR, but I've noted an issue on the review.  In any case we should agree on what goes in the repr here in this issue before actually implementing anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24337>
_______________________________________

From report at bugs.python.org  Wed Jan 22 15:53:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 20:53:33 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579726413.69.0.688892706076.issue39406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0852c7dd52ac42e7843ddfef44571494e4c86070 by Victor Stinner in branch 'master':
bpo-39406: os.putenv() avoids putenv_dict on Windows (GH-18126)
https://github.com/python/cpython/commit/0852c7dd52ac42e7843ddfef44571494e4c86070


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Wed Jan 22 16:03:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 21:03:44 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579727024.83.0.995815089014.issue39406@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17515
pull_request: https://github.com/python/cpython/pull/18128

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Wed Jan 22 16:06:45 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 22 Jan 2020 21:06:45 +0000
Subject: [issue39411] pyclbr rewrite using AST
In-Reply-To: <1579613369.33.0.216761296366.issue39411@roundup.psfhosted.org>
Message-ID: <1579727205.21.0.438626832837.issue39411@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

A separate doc change issue and PR would be fine.  Should we add a note explaining the module name as a contraction of an originally restricted scope?  Make me nosy and invite review.

Actually, a doc issue for the module as is should *fully* explain readmodule_ex first (its entry is now incomplete), and then explain readmodule as a filtered version kept for back compatibility.  This could be a separate PR on the same issue, written by one of us, if too much for your friend.

I understood limits of this PR. I should have said change notes were intended for your 'second PR'. 

Changing the return value to a Module should mean a third function, which would then become the main function, as readmodule_ex would then be Module.children.

I have thought about making it possible to browse non-source modules, at least for the module being browsed.  I might implement that first in IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39411>
_______________________________________

From report at bugs.python.org  Wed Jan 22 16:43:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 21:43:36 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579729416.97.0.712573165188.issue39425@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The following result is a little bit surprising:

>>> nan=float("nan"); ([nan]*5).count(nan)
5
>>> nan == nan
False

But in fact, the optimization doesn't change the value. It was already 5 previously.

In fact, PyObject_RichCompareBool() has a fast path if the two object pointers are equal:

    /* Quick result when objects are the same.
       Guarantees that identity implies equality. */
    if (v == w) {
        if (op == Py_EQ)
            return 1;
        else if (op == Py_NE)
            return 0;
    }

In short, the optimization is good: thank you ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 16:45:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 21:45:44 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579729544.28.0.679124483717.issue39425@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> In fact, PyObject_RichCompareBool() has a fast path if the two object pointers are equal

It's documented:

https://docs.python.org/dev/c-api/object.html?highlight=pyobject_richcomparebool#c.PyObject_RichCompareBool

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 16:48:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 21:48:19 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579729699.56.0.417513017008.issue39406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b477d19a6b7751b0c933b239dae4fc96dbcde9c4 by Victor Stinner in branch 'master':
bpo-39406: Implement os.putenv() with setenv() if available (GH-18128)
https://github.com/python/cpython/commit/b477d19a6b7751b0c933b239dae4fc96dbcde9c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Wed Jan 22 16:50:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Jan 2020 21:50:20 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579729820.32.0.00187751152588.issue39425@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> The following result is a little bit surprising:

haha, I went to exactly the same journey when reviewing this PR :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 16:59:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 21:59:02 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579730342.4.0.516924749499.issue39406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Serhiy:
> Maybe use SetEnvironmentVariable() on Windows?

In bpo-39413, I implemented os.unsetenv() on Windows using SetEnvironmentVariable(), but Eryk reported that SetEnvironmentVariable() does not update the CRT API (_environ, _wenviron, getenv, etc.). So I reverted my change. See bpo-39413 for the details.


Eryk:
> Windows ucrt copies the buffer that's passed to _[w]putenv.

Thank you for checking manually. I pushed commit 0852c7dd52ac42e7843ddfef44571494e4c86070 to avoid putenv_dict on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Wed Jan 22 16:59:47 2020
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Jan 2020 21:59:47 +0000
Subject: [issue39366] Remove deprecated nntplib method
In-Reply-To: <1579252275.31.0.83759168902.issue39366@roundup.psfhosted.org>
Message-ID: <1579730387.66.0.0125512347966.issue39366@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 1f0f102dec506fd06f912b74dd2be64a7fba0d3f by Berker Peksag (Dong-hee Na) in branch 'master':
bpo-39366: Remove xpath() and xgtitle() methods of NNTP (GH-18035)
https://github.com/python/cpython/commit/1f0f102dec506fd06f912b74dd2be64a7fba0d3f


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39366>
_______________________________________

From report at bugs.python.org  Wed Jan 22 17:00:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 22:00:40 +0000
Subject: [issue39406] Implement os.putenv() with setenv() if available
In-Reply-To: <1579595402.07.0.326081279431.issue39406@roundup.psfhosted.org>
Message-ID: <1579730440.95.0.981433331727.issue39406@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The initial issue has been fixed, so I close the issue. Big thanks to Eryk Sun for your great help, thanks also Serhiy Storchaka.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39406>
_______________________________________

From report at bugs.python.org  Wed Jan 22 17:01:26 2020
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 22 Jan 2020 22:01:26 +0000
Subject: [issue39366] Remove deprecated nntplib method
In-Reply-To: <1579252275.31.0.83759168902.issue39366@roundup.psfhosted.org>
Message-ID: <1579730486.27.0.483230324832.issue39366@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the PR! I'm glad these previously deprecated functions are now gone.

----------
components: +Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39366>
_______________________________________

From report at bugs.python.org  Wed Jan 22 17:03:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 22:03:22 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579730602.19.0.12336935299.issue39395@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I closed bpo-39406: os.putenv() is now implemented with setenv() if available. The internal putenv_dict is no longer used on Windows and if setenv() is available.

Now only non-Windows platforms without setenv() are affected by this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Wed Jan 22 17:12:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 22:12:38 +0000
Subject: [issue39425] list.count performance regression
In-Reply-To: <1579713363.79.0.989493842853.issue39425@roundup.psfhosted.org>
Message-ID: <1579731158.92.0.203736346034.issue39425@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17516
pull_request: https://github.com/python/cpython/pull/18130

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39425>
_______________________________________

From report at bugs.python.org  Wed Jan 22 17:26:44 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Jan 2020 22:26:44 +0000
Subject: [issue39427] python -X options are not documented in the CLI --help
Message-ID: <1579732004.75.0.619158264246.issue39427@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

When running python --help there is no documentation on the -X opt options available. It just says:

-X opt : set implementation-specific option

without what 'opt' can be.

----------
assignee: pablogsal
components: Interpreter Core
messages: 360516
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: python -X options are not documented in the CLI --help
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39427>
_______________________________________

From report at bugs.python.org  Wed Jan 22 17:28:27 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 22 Jan 2020 22:28:27 +0000
Subject: [issue39427] python -X options are not documented in the CLI --help
In-Reply-To: <1579732004.75.0.619158264246.issue39427@roundup.psfhosted.org>
Message-ID: <1579732107.14.0.185790800971.issue39427@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +17517
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18131

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39427>
_______________________________________

From report at bugs.python.org  Wed Jan 22 17:43:32 2020
From: report at bugs.python.org (Martin Panter)
Date: Wed, 22 Jan 2020 22:43:32 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579733012.24.0.124993020081.issue39353@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Is there a recommended replacement for calculating CRC-CCITT? Do it yourself in Python code, or use a particular external module?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Wed Jan 22 17:45:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 22 Jan 2020 22:45:08 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579733108.6.0.0885212027724.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Is there a recommended replacement for calculating CRC-CCITT? Do it yourself in Python code, or use a particular external module?

What is your use case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Wed Jan 22 18:21:58 2020
From: report at bugs.python.org (Martin Panter)
Date: Wed, 22 Jan 2020 23:21:58 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579735318.57.0.229314557791.issue39353@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Building and verifying the checksum in "RTA protocol" that uses this: <https://rms.nsw.gov.au/business-industry/partners-suppliers/documents/specifications/tsi-sp-003.pdf>. But I understand CRC-CCITT is one of the two popular 16-bit CRC polynomials, used in many other places, according to <https://en.wikipedia.org/wiki/Cyclic_redundancy_check#Polynomial_representations_of_cyclic_redundancy_checks>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Wed Jan 22 18:28:39 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 22 Jan 2020 23:28:39 +0000
Subject: [issue35182] Popen.communicate() breaks when child closes its side of
 pipe but not exits
In-Reply-To: <1541586210.62.0.788709270274.issue35182@psf.upfronthosting.co.za>
Message-ID: <1579735719.12.0.548172549575.issue35182@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset d3ae95e1e945ed20297e1c38ba43a18b7a868ab6 by Gregory P. Smith (Alex Rebert) in branch 'master':
bpo-35182: fix communicate() crash after child closes its pipes (GH-17020) (GH-18117)
https://github.com/python/cpython/commit/d3ae95e1e945ed20297e1c38ba43a18b7a868ab6


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35182>
_______________________________________

From report at bugs.python.org  Wed Jan 22 18:31:30 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 22 Jan 2020 23:31:30 +0000
Subject: [issue35182] Popen.communicate() breaks when child closes its side of
 pipe but not exits
In-Reply-To: <1541586210.62.0.788709270274.issue35182@psf.upfronthosting.co.za>
Message-ID: <1579735890.95.0.592022423451.issue35182@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

backport automation appears unhappy at the moment.  I'm keeping this open and assigned to me to manually run cherry_picker on this for 3.8 and 3.7 (if still open for non-security fixes).

----------
assignee:  -> gregory.p.smith
stage: patch review -> backport needed
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35182>
_______________________________________

From report at bugs.python.org  Wed Jan 22 18:44:18 2020
From: report at bugs.python.org (Carl Meyer)
Date: Wed, 22 Jan 2020 23:44:18 +0000
Subject: [issue39428] allow creation of "symtable entry" objects from Python
Message-ID: <1579736658.27.0.540256787328.issue39428@roundup.psfhosted.org>


New submission from Carl Meyer <carl at oddbird.net>:

Currently the "symtable entry" extension type (PySTEntry_Type) defined in `Python/symtable.c` defines no `tp_new` or `tp_init`, making it impossible to create instances of this type from Python code.

I have a use case for pickling symbol tables (as part of a cache subsystem for a static analyzer), but the inability to create instances of symtable entries from attributes makes this impossible, even with custom pickle support via dispatch_table or copyreg.

If the idea of making instances of this type creatable from Python is accepted in principle, I can submit a PR for it.

Thanks!

----------
messages: 360522
nosy: carljm
priority: normal
severity: normal
status: open
title: allow creation of "symtable entry" objects from Python
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39428>
_______________________________________

From report at bugs.python.org  Wed Jan 22 18:53:41 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 22 Jan 2020 23:53:41 +0000
Subject: [issue37444] Differing exception between builtins and importlib when
 importing beyond top-level package
In-Reply-To: <1561749733.32.0.955430999512.issue37444@roundup.psfhosted.org>
Message-ID: <1579737221.79.0.727536936827.issue37444@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

For the record, looking at https://docs.python.org/3.9/whatsnew/3.9.html I had an impression that this also affects regular imports, as described in https://bugzilla.redhat.com/show_bug.cgi?id=1791769#c2 -- if that's not that case, I'm sorry.

Anyway, I get your point of "next 30 years of Python".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37444>
_______________________________________

From report at bugs.python.org  Wed Jan 22 19:18:03 2020
From: report at bugs.python.org (William Chargin)
Date: Thu, 23 Jan 2020 00:18:03 +0000
Subject: [issue39389] gzip metadata fails to reflect compresslevel
In-Reply-To: <1579465438.04.0.91237843457.issue39389@roundup.psfhosted.org>
Message-ID: <1579738683.13.0.980836293607.issue39389@roundup.psfhosted.org>


William Chargin <wchargin at gmail.com> added the comment:

My pleasure; thanks for the triage and review!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39389>
_______________________________________

From report at bugs.python.org  Wed Jan 22 19:42:44 2020
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 23 Jan 2020 00:42:44 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1579740164.4.0.307976420147.issue39336@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:


New changeset 9b6fec46513006d7b06fcb645cca6e4f5bf7c7b8 by Dino Viehland in branch 'master':
bpo-39336: Allow packages to not let their child modules be set on them (#18006)
https://github.com/python/cpython/commit/9b6fec46513006d7b06fcb645cca6e4f5bf7c7b8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Wed Jan 22 19:57:27 2020
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 23 Jan 2020 00:57:27 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1579741047.19.0.363749934574.issue39336@roundup.psfhosted.org>


Change by Dino Viehland <dinoviehland at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Wed Jan 22 20:03:08 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 01:03:08 +0000
Subject: [issue39427] python -X options are not documented in the CLI --help
In-Reply-To: <1579732004.75.0.619158264246.issue39427@roundup.psfhosted.org>
Message-ID: <1579741388.54.0.643658535786.issue39427@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 41f0ef6abbd304409c55612a08788cdd59fbc8a3 by Miss Islington (bot) (Pablo Galindo) in branch 'master':
bpo-39427: Document -X opt options in the CLI --help and the man page (GH-18131)
https://github.com/python/cpython/commit/41f0ef6abbd304409c55612a08788cdd59fbc8a3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39427>
_______________________________________

From report at bugs.python.org  Wed Jan 22 20:03:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jan 2020 01:03:16 +0000
Subject: [issue39429] Add a new "Python Development Mode" page to the
 documentation
Message-ID: <1579741396.58.0.897370884771.issue39429@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Currently, the Python Development Mode is under-documented. The documentation lives in the documentation of the -X command line option which doesn't give much space to elaborate on effects of the development mode, how it should be used, suggest ways to get more information, etc.

Attached PR adds a new "Python Development Mode" page to the documentation to suggest more advices and add examples.

----------
assignee: docs at python
components: Documentation
messages: 360527
nosy: docs at python, vstinner
priority: normal
severity: normal
status: open
title: Add a new "Python Development Mode" page to the documentation
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39429>
_______________________________________

From report at bugs.python.org  Wed Jan 22 20:29:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jan 2020 01:29:39 +0000
Subject: [issue39429] Add a new "Python Development Mode" page to the
 documentation
In-Reply-To: <1579741396.58.0.897370884771.issue39429@roundup.psfhosted.org>
Message-ID: <1579742979.12.0.968276953846.issue39429@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17518
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18132

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39429>
_______________________________________

From report at bugs.python.org  Wed Jan 22 20:34:13 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Jan 2020 01:34:13 +0000
Subject: [issue39427] python -X options are not documented in the CLI --help
In-Reply-To: <1579732004.75.0.619158264246.issue39427@roundup.psfhosted.org>
Message-ID: <1579743253.12.0.117096953065.issue39427@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +17519
pull_request: https://github.com/python/cpython/pull/18133

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39427>
_______________________________________

From report at bugs.python.org  Wed Jan 22 20:40:10 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Jan 2020 01:40:10 +0000
Subject: [issue39427] python -X options are not documented in the CLI --help
In-Reply-To: <1579732004.75.0.619158264246.issue39427@roundup.psfhosted.org>
Message-ID: <1579743610.62.0.989418651461.issue39427@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +17520
pull_request: https://github.com/python/cpython/pull/18134

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39427>
_______________________________________

From report at bugs.python.org  Wed Jan 22 20:50:25 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 23 Jan 2020 01:50:25 +0000
Subject: [issue39412] Install launcher for all users
In-Reply-To: <1579617264.58.0.64528608209.issue39412@roundup.psfhosted.org>
Message-ID: <1579744225.04.0.842208342559.issue39412@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39412>
_______________________________________

From report at bugs.python.org  Wed Jan 22 20:52:21 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 23 Jan 2020 01:52:21 +0000
Subject: [issue39412] Install launcher for all users
In-Reply-To: <1579617264.58.0.64528608209.issue39412@roundup.psfhosted.org>
Message-ID: <1579744341.65.0.105424845067.issue39412@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It's also a little bit historical - there was no way to *remove* the Python 3.4 launcher (always in C:\Windows), and it wasn't going to find many 3.5 installs, so we stomp on it.

At this stage, it's potentially safe to turn it into a per-user install by default, but I'm not convinced it's a big enough issue to make the change. The only "complaints" I've ever heard have been like this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39412>
_______________________________________

From report at bugs.python.org  Wed Jan 22 20:56:01 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 23 Jan 2020 01:56:01 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1579744561.09.0.770259231495.issue39401@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Agreed, we can just search System32 for this. Thanks for doing the patch!

For future reference, and for anyone else reading this, we generally prefer unavoidable DLL hijacking bugs to come to the Python Security Response Team first (security at python.org).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Wed Jan 22 21:07:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jan 2020 02:07:40 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579745260.28.0.388751326157.issue39395@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17521
pull_request: https://github.com/python/cpython/pull/18135

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Wed Jan 22 21:11:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jan 2020 02:11:25 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579745485.24.0.633084843798.issue39395@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Clearing environment variables at exit has a drawback: it changes the behavior in code executed after Python finalization (Py_FinalizeEx() call). It may cause regression.

So I proposed PR 18135 to fix this issue differently: on non-Windows platforms, Python now requires setenv() to build. This PR has no backward compatibility issue: it doesn't unset environment variables at exit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Wed Jan 22 21:24:28 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 23 Jan 2020 02:24:28 +0000
Subject: [issue29435] Allow to pass fileobj to is_tarfile
In-Reply-To: <1486132653.21.0.166387912558.issue29435@psf.upfronthosting.co.za>
Message-ID: <1579746268.62.0.743858399134.issue29435@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset dd754caf144009f0569dda5053465ba2accb7b4d by Ethan Furman (William Woodruff) in branch 'master':
bpo-29435: Allow is_tarfile to take a filelike obj (GH-18090)
https://github.com/python/cpython/commit/dd754caf144009f0569dda5053465ba2accb7b4d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29435>
_______________________________________

From report at bugs.python.org  Wed Jan 22 21:26:01 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 23 Jan 2020 02:26:01 +0000
Subject: [issue29435] Allow to pass fileobj to is_tarfile
In-Reply-To: <1486132653.21.0.166387912558.issue29435@psf.upfronthosting.co.za>
Message-ID: <1579746361.09.0.704855785207.issue29435@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Thanks, William!

----------
assignee:  -> ethan.furman
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29435>
_______________________________________

From report at bugs.python.org  Wed Jan 22 21:50:14 2020
From: report at bugs.python.org (William Woodruff)
Date: Thu, 23 Jan 2020 02:50:14 +0000
Subject: [issue29435] Allow to pass fileobj to is_tarfile
In-Reply-To: <1486132653.21.0.166387912558.issue29435@psf.upfronthosting.co.za>
Message-ID: <1579747814.34.0.594001154537.issue29435@roundup.psfhosted.org>


William Woodruff <william at yossarian.net> added the comment:

Thanks to you to!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29435>
_______________________________________

From report at bugs.python.org  Wed Jan 22 22:18:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 23 Jan 2020 03:18:48 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579749528.49.0.372139224284.issue39353@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Wed Jan 22 22:30:55 2020
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 23 Jan 2020 03:30:55 +0000
Subject: [issue39279] Don't allow non-Ascii digits in platform.py
In-Reply-To: <1578603731.26.0.701759063569.issue39279@roundup.psfhosted.org>
Message-ID: <1579750255.93.0.968440443183.issue39279@roundup.psfhosted.org>


Xiang Zhang <angwerzx at 126.com> added the comment:

I can't understand the rational for rejecting localized digits though I don't know who will use them in practise. I'd rather fix it until there is a real problem with it.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39279>
_______________________________________

From report at bugs.python.org  Wed Jan 22 22:37:19 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 23 Jan 2020 03:37:19 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1579750639.21.0.490639259512.issue39401@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
priority: normal -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Wed Jan 22 22:39:19 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 23 Jan 2020 03:39:19 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1579750759.36.0.371253850124.issue39401@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Wed Jan 22 22:52:40 2020
From: report at bugs.python.org (Jack O'Connor)
Date: Thu, 23 Jan 2020 03:52:40 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1579751560.78.0.614099082415.issue39298@roundup.psfhosted.org>


Jack O'Connor <oconnor663 at gmail.com> added the comment:

Version 0.1.3 of the official BLAKE3 repo includes some significant performance improvements:

- The x86 implementations include explicit prefetch instructions, which helps with long inputs. (commit b8c33e1)
- The C implementation now uses the same parallel parent hashing strategy that the Rust implementation uses. (commit 163f522)

When I repeat the benchmarks above with TurboBoost on, here's what I see now:

BLAKE3 Rust          2578 MB/s
BLAKE3 C (clang -O3) 2502 MB/s
BLAKE3 C (gcc -O2)   2223 MB/s
K12 C (gcc -O2)      2175 MB/s

Larry, if you have time to repeat your benchmarks with the latest C code, I'd be curious to see if you get similar results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Wed Jan 22 22:54:33 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2020 03:54:33 +0000
Subject: [issue39050] The "Help" button in IDLE's config dialog does not work
In-Reply-To: <1576360901.2.0.273955220755.issue39050@roundup.psfhosted.org>
Message-ID: <1579751673.86.0.475574729367.issue39050@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 2e43b64c94e49f7133b9c26e84c9519935c49063 by Terry Jan Reedy (Zackery Spytz) in branch 'master':
bpo-39050: The Help button in IDLE's config menu works again (GH-17611)
https://github.com/python/cpython/commit/2e43b64c94e49f7133b9c26e84c9519935c49063


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39050>
_______________________________________

From report at bugs.python.org  Wed Jan 22 22:54:45 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 03:54:45 +0000
Subject: [issue39050] The "Help" button in IDLE's config dialog does not work
In-Reply-To: <1576360901.2.0.273955220755.issue39050@roundup.psfhosted.org>
Message-ID: <1579751685.26.0.977487972848.issue39050@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17522
pull_request: https://github.com/python/cpython/pull/18136

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39050>
_______________________________________

From report at bugs.python.org  Wed Jan 22 22:55:32 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 03:55:32 +0000
Subject: [issue39050] The "Help" button in IDLE's config dialog does not work
In-Reply-To: <1576360901.2.0.273955220755.issue39050@roundup.psfhosted.org>
Message-ID: <1579751732.03.0.831220114028.issue39050@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17523
pull_request: https://github.com/python/cpython/pull/18137

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39050>
_______________________________________

From report at bugs.python.org  Wed Jan 22 23:11:56 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 04:11:56 +0000
Subject: [issue39050] The "Help" button in IDLE's config dialog does not work
In-Reply-To: <1576360901.2.0.273955220755.issue39050@roundup.psfhosted.org>
Message-ID: <1579752716.68.0.197764015218.issue39050@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ba83d1eb1c7b5e8eab17da364a6324b0b0e0932b by Miss Islington (bot) in branch '3.7':
bpo-39050: The Help button in IDLE's config menu works again (GH-17611)
https://github.com/python/cpython/commit/ba83d1eb1c7b5e8eab17da364a6324b0b0e0932b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39050>
_______________________________________

From report at bugs.python.org  Wed Jan 22 23:13:33 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 04:13:33 +0000
Subject: [issue39050] The "Help" button in IDLE's config dialog does not work
In-Reply-To: <1576360901.2.0.273955220755.issue39050@roundup.psfhosted.org>
Message-ID: <1579752813.36.0.904019287679.issue39050@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3b7618809df647574e8aad4c2d869a1d55df147c by Miss Islington (bot) in branch '3.8':
bpo-39050: The Help button in IDLE's config menu works again (GH-17611)
https://github.com/python/cpython/commit/3b7618809df647574e8aad4c2d869a1d55df147c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39050>
_______________________________________

From report at bugs.python.org  Wed Jan 22 23:20:01 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2020 04:20:01 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579753201.83.0.0571300169142.issue32989@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Cheryl, sorry to take so long.  I will look at and probably remove the _synchre parameter, on this issue.  Feel free to pursue any of the other possible followups.

----------
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Wed Jan 22 23:30:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2020 04:30:00 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579753800.62.0.0141210730815.issue32989@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Tim, idlelib.pyparse has this definition:

# Find what looks like the start of a popular statement.
_synchre = re.compile(r"""
    ^
    [ \t]*
    (?: while
    |   else
    |   def
    |   return
    |   assert
    |   break
    |   class
    |   continue
    |   elif
    |   try
    |   except
    |   raise
    |   import
    |   yield
    )
    \b
""", re.VERBOSE | re.MULTILINE).search

You are credited with adding 'yield' to David Sherer's original list:
  "Taught IDLE's autoident parser that "yield" is a keyword that begins
   a stmt." --tim_one (found via git blame)

Do you know if there is any reason to not add 'if', 'for', and now 'with'?

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Wed Jan 22 23:34:06 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2020 04:34:06 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579754046.64.0.271088047635.issue32989@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +17524
pull_request: https://github.com/python/cpython/pull/18138

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Wed Jan 22 23:52:33 2020
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 23 Jan 2020 04:52:33 +0000
Subject: [issue39279] Don't allow non-Ascii digits in platform.py
In-Reply-To: <1578603731.26.0.701759063569.issue39279@roundup.psfhosted.org>
Message-ID: <1579755153.28.0.275849056848.issue39279@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Do you know/can you verify if Chinese versions of Windows/Linux/MacOS  include non-ASCII version numbers (e.g. fullwidth digits)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39279>
_______________________________________

From report at bugs.python.org  Wed Jan 22 23:55:20 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 04:55:20 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579755320.03.0.854770199459.issue32989@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17525
pull_request: https://github.com/python/cpython/pull/18139

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Wed Jan 22 23:55:11 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2020 04:55:11 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579755311.56.0.130417345712.issue32989@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset f9e07e116c32b6dc4561d0bdeb452ccde13b0e7c by Terry Jan Reedy in branch 'master':
bpo-32989: IDLE - remove unneeded parameter  (GH-18138)
https://github.com/python/cpython/commit/f9e07e116c32b6dc4561d0bdeb452ccde13b0e7c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Wed Jan 22 23:55:26 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 04:55:26 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579755326.47.0.0120608986835.issue32989@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17526
pull_request: https://github.com/python/cpython/pull/18140

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Thu Jan 23 00:13:04 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 05:13:04 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579756384.31.0.860554929185.issue32989@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 36968c13cb9800559dbb90686933da7daf52c788 by Miss Islington (bot) in branch '3.7':
bpo-32989: IDLE - remove unneeded parameter  (GH-18138)
https://github.com/python/cpython/commit/36968c13cb9800559dbb90686933da7daf52c788


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Thu Jan 23 00:13:44 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 05:13:44 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579756424.54.0.505649099586.issue32989@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 545fc51d950558ecec9ff64cb2f9c11469051524 by Miss Islington (bot) in branch '3.8':
bpo-32989: IDLE - remove unneeded parameter  (GH-18138)
https://github.com/python/cpython/commit/545fc51d950558ecec9ff64cb2f9c11469051524


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Thu Jan 23 00:40:08 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 23 Jan 2020 05:40:08 +0000
Subject: [issue35003] Provide an option to venv to put files in a bin/
 directory on Windows
In-Reply-To: <1539727932.79.0.788709270274.issue35003@psf.upfronthosting.co.za>
Message-ID: <1579758008.8.0.538372240487.issue35003@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> This *should* reside in the bin directory

That's your opinion, but there are other views. As Paul Moore said in this comment:

https://github.com/python/cpython/pull/18083#issuecomment-577278587

Having things in bin *and* Scripts is more confusing than "on Windows use Scripts, on POSIX use bin".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35003>
_______________________________________

From report at bugs.python.org  Thu Jan 23 00:45:49 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 23 Jan 2020 05:45:49 +0000
Subject: [issue38921] Max Recursion Depth Reached in Logging Library
In-Reply-To: <1574793583.29.0.769726111814.issue38921@roundup.psfhosted.org>
Message-ID: <1579758348.99.0.767358596565.issue38921@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

@yang, thanks for the analysis - spot on. Closing, as this is a bug in the reporter's code and not in logging.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38921>
_______________________________________

From report at bugs.python.org  Thu Jan 23 00:47:34 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 23 Jan 2020 05:47:34 +0000
Subject: [issue39295] usage of bitfields in ctypes structures changed between
 3.7.5 and 3.7.6
In-Reply-To: <1578694567.2.0.498689301236.issue39295@roundup.psfhosted.org>
Message-ID: <1579758454.9.0.771903312944.issue39295@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39295>
_______________________________________

From report at bugs.python.org  Thu Jan 23 02:11:51 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2020 07:11:51 +0000
Subject: [issue32989] IDLE: Fix pyparse.find_good_parse_start
In-Reply-To: <1520037876.54.0.467229070634.issue32989@psf.upfronthosting.co.za>
Message-ID: <1579763511.93.0.354926068232.issue32989@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32989>
_______________________________________

From report at bugs.python.org  Thu Jan 23 02:49:15 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 23 Jan 2020 07:49:15 +0000
Subject: [issue39407] Bitfield Union does not work for bit widths greater than
 8 bits
In-Reply-To: <1579598446.4.0.992885601922.issue39407@roundup.psfhosted.org>
Message-ID: <1579765755.93.0.28505061631.issue39407@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39407>
_______________________________________

From report at bugs.python.org  Thu Jan 23 02:55:43 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Jan 2020 07:55:43 +0000
Subject: [issue39279] Don't allow non-Ascii digits in platform.py
In-Reply-To: <1578603731.26.0.701759063569.issue39279@roundup.psfhosted.org>
Message-ID: <1579766143.54.0.719920454234.issue39279@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> If you think I need to come up with a specific example where this can be misused

I think so, yes. :-)

We shouldn't change this (and risk other breakage) without evidence that there's an actual problem.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39279>
_______________________________________

From report at bugs.python.org  Thu Jan 23 04:25:21 2020
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 23 Jan 2020 09:25:21 +0000
Subject: [issue39320] Handle unpacking of */** arguments and rvalues in the
 compiler
In-Reply-To: <1578918490.54.0.342025462897.issue39320@roundup.psfhosted.org>
Message-ID: <1579771521.35.0.180373332398.issue39320@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 13bc13960cc83dbd1cb5701d9a59ac9b9144b205 by Mark Shannon in branch 'master':
bpo-39320: Handle unpacking of *values in compiler (GH-17984)
https://github.com/python/cpython/commit/13bc13960cc83dbd1cb5701d9a59ac9b9144b205


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39320>
_______________________________________

From report at bugs.python.org  Thu Jan 23 04:38:11 2020
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 23 Jan 2020 09:38:11 +0000
Subject: [issue39320] Handle unpacking of */** arguments and rvalues in the
 compiler
In-Reply-To: <1578918490.54.0.342025462897.issue39320@roundup.psfhosted.org>
Message-ID: <1579772291.25.0.968967105768.issue39320@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +17527
pull_request: https://github.com/python/cpython/pull/18141

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39320>
_______________________________________

From report at bugs.python.org  Thu Jan 23 05:44:20 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 23 Jan 2020 10:44:20 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
Message-ID: <1579776260.84.0.333075912412.issue39380@roundup.psfhosted.org>


New submission from Eric V. Smith <eric at trueblade.com>:

What's the reason behind this change? I love UTF-8 and all, but is there some standard (de facto or de jure) that discusses this?

What does this change fix? What's the implication to existing clients?

I'm not opposed to the change per se, but I'd like to understand the reasoning.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Thu Jan 23 05:55:42 2020
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 23 Jan 2020 10:55:42 +0000
Subject: [issue39279] Don't allow non-Ascii digits in platform.py
In-Reply-To: <1578603731.26.0.701759063569.issue39279@roundup.psfhosted.org>
Message-ID: <1579776942.48.0.56584188482.issue39279@roundup.psfhosted.org>


Xiang Zhang <angwerzx at 126.com> added the comment:

@Ezio, at least for my config they are all ASCII digits. But still I don't think there is any rush to change current behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39279>
_______________________________________

From report at bugs.python.org  Thu Jan 23 06:15:38 2020
From: report at bugs.python.org (Maciej Gol)
Date: Thu, 23 Jan 2020 11:15:38 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
Message-ID: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>


New submission from Maciej Gol <maciej.gol at curo.ch>:

Hey guys,

We have a component that archives and unarchives multiple files in separate threads that started to
misbehave recently.

We have noticed a bunch of `AttributeError: module 'lzma' has no attribute 'LZMAFile'` errors, which are
unexpected because our python is not compiled with LZMA support.

What is unfortunate, is that given the traceback:

    Traceback (most recent call last):
      File "test.py", line 18, in <module>
        list(pool.map(test_lzma, range(100)))
      File "/opt/lang/python37/lib/python3.7/concurrent/futures/_base.py", line 598, in result_iterator
        yield fs.pop().result()
      File "/opt/lang/python37/lib/python3.7/concurrent/futures/_base.py", line 428, in result
        return self.__get_result()
      File "/opt/lang/python37/lib/python3.7/concurrent/futures/_base.py", line 384, in __get_result
        raise self._exception
      File "/opt/lang/python37/lib/python3.7/concurrent/futures/thread.py", line 57, in run
        result = self.fn(*self.args, **self.kwargs)
      File "test.py", line 14, in test_lzma
        tarfile.open(fileobj=buf, mode="r")
      File "/opt/lang/python37/lib/python3.7/tarfile.py", line 1573, in open
        return func(name, "r", fileobj, **kwargs)
      File "/opt/lang/python37/lib/python3.7/tarfile.py", line 1699, in xzopen
        fileobj = lzma.LZMAFile(fileobj or name, mode, preset=preset)
    AttributeError: module 'lzma' has no attribute 'LZMAFile'


the last line of the traceback is right AFTER this block (tarfile.py:1694):

    try:
        import lzma
    except ImportError:
        raise CompressionError("lzma module is not available")


Importing lzma in ipython fails properly:

    In [2]: import lzma                                                                                                                               
    ---------------------------------------------------------------------------
    ModuleNotFoundError                       Traceback (most recent call last)
    <ipython-input-2-c0255b54beb9> in <module>
    ----> 1 import lzma

    /opt/lang/python37/lib/python3.7/lzma.py in <module>
        25 import io
        26 import os
    ---> 27 from _lzma import *
        28 from _lzma import _encode_filter_properties, _decode_filter_properties
        29 import _compression

    ModuleNotFoundError: No module named '_lzma'

When trying to debug the problem, we have noticed it's not deterministic. In order to reproduce it,
we have created a test python that repeatedly writes an archive to BytesIO and then reads from it.
Using it with 5 threads and 100 calls, gives very good chances of reproducing the issue. For us it
was almost every time.

Race condition occurs both on Python 3.7.3 and 3.7.6.
Test script used to reproduce it attached.

I know that the test script writes uncompressed archives and during opening tries to guess the compression.
But I guess this is a legitimate scenario and should not matter in this case.

----------
files: test.py
messages: 360551
nosy: Maciej Gol
priority: normal
severity: normal
status: open
title: tarfile.open(mode="r") race condition when importing lzma
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48860/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Thu Jan 23 06:19:25 2020
From: report at bugs.python.org (Maciej Gol)
Date: Thu, 23 Jan 2020 11:19:25 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579778365.91.0.783330244191.issue39430@roundup.psfhosted.org>


Maciej Gol <maciej.gol at curo.ch> added the comment:

Uploading fixed file (the former had a typo)

----------
Added file: https://bugs.python.org/file48861/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Thu Jan 23 06:19:33 2020
From: report at bugs.python.org (Maciej Gol)
Date: Thu, 23 Jan 2020 11:19:33 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579778373.75.0.609010789065.issue39430@roundup.psfhosted.org>


Change by Maciej Gol <maciej.gol at curo.ch>:


Removed file: https://bugs.python.org/file48860/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Thu Jan 23 06:40:24 2020
From: report at bugs.python.org (Shanavas M)
Date: Thu, 23 Jan 2020 11:40:24 +0000
Subject: [issue39431] Mention nonlocal too in assignment quirk
Message-ID: <1579779624.25.0.960153197022.issue39431@roundup.psfhosted.org>


New submission from Shanavas M <shanavas.m2 at gmail.com>:

Doc says "A special quirk of Python is that -- if no :keyword:`global` statement is in	A special quirk of Python is that -- if no :keyword:`global` or :keyword:`nonlocal`
effect -- assignments to names always go into the innermost scope."

nonlocal should also be mentioned along with global

----------
assignee: docs at python
components: Documentation
messages: 360553
nosy: docs at python, shanavasm
priority: normal
pull_requests: 17528
severity: normal
status: open
title: Mention nonlocal too in assignment quirk
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39431>
_______________________________________

From report at bugs.python.org  Thu Jan 23 07:12:14 2020
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Thu, 23 Jan 2020 12:12:14 +0000
Subject: [issue17659] no way to determine First weekday (based on locale)
In-Reply-To: <1365410883.64.0.172005963141.issue17659@psf.upfronthosting.co.za>
Message-ID: <1579781534.31.0.592280474346.issue17659@roundup.psfhosted.org>


Change by C?dric Krier <cedric.krier at b2ck.com>:


----------
pull_requests: +17529
pull_request: https://github.com/python/cpython/pull/18142

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17659>
_______________________________________

From report at bugs.python.org  Thu Jan 23 07:29:38 2020
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Thu, 23 Jan 2020 12:29:38 +0000
Subject: [issue17659] no way to determine First weekday (based on locale)
In-Reply-To: <1365410883.64.0.172005963141.issue17659@psf.upfronthosting.co.za>
Message-ID: <1579782578.66.0.805192281519.issue17659@roundup.psfhosted.org>


C?dric Krier <cedric.krier at b2ck.com> added the comment:

I submitted https://github.com/python/cpython/pull/18142 which implements (based on the initial patch) a function locale.getfirstweekday(). The implementation supports glibc (if _NL_TIME_FIRST_WEEKDAY is defined) and Windows (not yet tested).
I did not keep the nl_langinfo because I do not think it is good to have platform dependent definition.

----------
nosy: +ced
versions: +Python 3.9 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17659>
_______________________________________

From report at bugs.python.org  Thu Jan 23 08:48:15 2020
From: report at bugs.python.org (da-woods)
Date: Thu, 23 Jan 2020 13:48:15 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
Message-ID: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>


New submission from da-woods <dw-git at d-woods.co.uk>:

Distuitls generates "export symbols" for extension modules to help ensure that they have have the correct linkage on Windows.

https://github.com/python/cpython/blob/0d30ae1a03102de07758650af9243fd31211325a/Lib/distutils/command/build_ext.py#L692

It generates the correct symbol in most causes, but if the filename contains unicode characters then it creates the wrong symbol, causing linkage errors.

The behaviour should be updated to reflect PEP-489: https://www.python.org/dev/peps/pep-0489/#export-hook-name

----------
components: Distutils
messages: 360555
nosy: da-woods, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Distutils generates the wrong export symbol for unicode module names
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/issue39432>
_______________________________________

From report at bugs.python.org  Thu Jan 23 08:54:44 2020
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 23 Jan 2020 13:54:44 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579787684.42.0.955486784355.issue39421@roundup.psfhosted.org>


Change by Alex Gaynor <alex.gaynor at gmail.com>:


----------
keywords: +security_issue
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Thu Jan 23 08:57:19 2020
From: report at bugs.python.org (Julien Palard)
Date: Thu, 23 Jan 2020 13:57:19 +0000
Subject: [issue39433] curses.setupterm can raise _curses.error
Message-ID: <1579787839.53.0.046587762459.issue39433@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

Currently the curses module can raise some `_curses.error` exception directly inheriting `Exception`.

This make it non-trivial for a newcomer to catch (they think they need a `from _curses import error`, or an `except Exception`, but in fact `error` is imported, in `curses/__init__.py`, in an `_curses import *`).

The `curses.error` is documented, but it's not documented that `curses.setupterm` can raise it and what the user sees on the exception message is "_curses.error" not "curses.error".


Questions:

- Should we create a properly named curse.CurseException, inheriting from _curses.error, so people can slowly migrate to use a "properly" named exception class?
- Should we document that setupterm can raise it?
- Should we introduce a dedicated sphinx directive to document exceptions?

I know the third question opens a whole field of work in the doc, it's only an anecdote but a student of mine pointed out yesterday that the doc is *not* telling what `int()` raises when an invalid argument is given. It's obvious for "us", but not for everybody (Yes I can teach it, yes he can just try it, but I'm not behind everyone on earth learning Python, some are learning alone, and I also want them to succeed).

----------
components: Library (Lib)
messages: 360556
nosy: mdk
priority: normal
severity: normal
status: open
title: curses.setupterm can raise _curses.error
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39433>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:07:16 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Jan 2020 14:07:16 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579788436.83.0.633905561694.issue39421@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 79f89e6e5a659846d1068e8b1bd8e491ccdef861 by Pablo Galindo in branch 'master':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118)
https://github.com/python/cpython/commit/79f89e6e5a659846d1068e8b1bd8e491ccdef861


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:07:29 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 14:07:29 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579788449.43.0.880896654132.issue39421@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17530
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18144

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:07:37 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 14:07:37 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579788457.06.0.60376115281.issue39421@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17531
pull_request: https://github.com/python/cpython/pull/18145

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:07:43 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 14:07:43 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579788463.83.0.910059534449.issue39421@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17532
pull_request: https://github.com/python/cpython/pull/18146

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:21:10 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 23 Jan 2020 14:21:10 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1579789270.88.0.706790314518.issue39432@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39432>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:21:29 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 23 Jan 2020 14:21:29 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1579789289.85.0.901577727047.issue39432@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39432>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:25:34 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 14:25:34 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579789534.9.0.0668278176095.issue39421@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 958064f8d2b84062b0582bbae911df8ccfc11fd6 by Miss Islington (bot) in branch '3.7':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118)
https://github.com/python/cpython/commit/958064f8d2b84062b0582bbae911df8ccfc11fd6


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:31:39 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Jan 2020 14:31:39 +0000
Subject: [issue39434] Add float __floordiv__ fast path
Message-ID: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

./python.exe -m pyperf timeit "a = 3.5" "b = a // 2"
AS-IS: Mean +- std dev: 377 ns +- 4 ns
my patch: Mean +- std dev: 204 ns +- 2 ns

----------
assignee: corona10
messages: 360559
nosy: corona10
priority: normal
severity: normal
status: open
title: Add float __floordiv__ fast path

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:31:48 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Jan 2020 14:31:48 +0000
Subject: [issue39434] Add float __floordiv__ fast path
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1579789908.56.0.839993262007.issue39434@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:35:46 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Jan 2020 14:35:46 +0000
Subject: [issue39434] Add float __floordiv__ fast path
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1579790146.33.0.742257939835.issue39434@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17533
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18147

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:38:24 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Jan 2020 14:38:24 +0000
Subject: [issue39434] Add float __floordiv__ fast path
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1579790304.54.0.57362557048.issue39434@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Is this worth optimising? Floating-point floor division is a comparatively rare operation.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:49:23 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 23 Jan 2020 14:49:23 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579790963.59.0.264669452066.issue39421@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset c563f409ea30bcb0623d785428c9257917371b76 by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118) (GH-18146)
https://github.com/python/cpython/commit/c563f409ea30bcb0623d785428c9257917371b76


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Thu Jan 23 09:56:41 2020
From: report at bugs.python.org (Alex Rebert)
Date: Thu, 23 Jan 2020 14:56:41 +0000
Subject: [issue35182] Popen.communicate() breaks when child closes its side of
 pipe but not exits
In-Reply-To: <1541586210.62.0.788709270274.issue35182@psf.upfronthosting.co.za>
Message-ID: <1579791401.84.0.40698541556.issue35182@roundup.psfhosted.org>


Change by Alex Rebert <alexandre.rebert at gmail.com>:


----------
pull_requests: +17534
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/18148

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35182>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:05:37 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 15:05:37 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579791937.69.0.591187292833.issue39421@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17535
pull_request: https://github.com/python/cpython/pull/18149

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:10:07 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 23 Jan 2020 15:10:07 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1579792207.22.0.965527066987.issue39432@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
keywords: +patch
pull_requests: +17536
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18150

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39432>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:16:31 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Thu, 23 Jan 2020 15:16:31 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1579792591.58.0.329951964207.issue39432@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39432>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:16:53 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Jan 2020 15:16:53 +0000
Subject: [issue39434] Add float __floordiv__ fast path
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1579792613.84.0.104344889291.issue39434@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> Is this worth optimizing? Floating-point floor division is a comparatively rare operation.

1. I don't want to say that this should always be optimized.
2. However, this operation is a relatively primitive python operation. I think this optimization is easy to bring and worth it.
3. Besides, the relatively unchanged logic, so the maintenance cost is not expected to be large

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:18:43 2020
From: report at bugs.python.org (Alex Rebert)
Date: Thu, 23 Jan 2020 15:18:43 +0000
Subject: [issue35182] Popen.communicate() breaks when child closes its side of
 pipe but not exits
In-Reply-To: <1541586210.62.0.788709270274.issue35182@psf.upfronthosting.co.za>
Message-ID: <1579792723.41.0.829443911542.issue35182@roundup.psfhosted.org>


Change by Alex Rebert <alexandre.rebert at gmail.com>:


----------
pull_requests: +17537
pull_request: https://github.com/python/cpython/pull/18151

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35182>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:20:50 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Jan 2020 15:20:50 +0000
Subject: [issue39434] Add float __floordiv__ fast path
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1579792850.96.0.760941289512.issue39434@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

And on the other side,

>>> 3.8 // 0.0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: float divmod()

I think that people expect 
ZeroDivisionError: float floor division by zero

not the current message.
I caught this optimization issue during I investigate about the error message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:22:29 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 15:22:29 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579792949.55.0.411790442321.issue39421@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 993811ffe75c2573f97fb3fd1414b34609b8c8db by Miss Islington (bot) in branch '3.8':
bpo-39421: Fix posible crash in heapq with custom comparison operators (GH-18118)
https://github.com/python/cpython/commit/993811ffe75c2573f97fb3fd1414b34609b8c8db


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:23:27 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Jan 2020 15:23:27 +0000
Subject: [issue39421] Use-after-free in heappushpop() of heapq module
In-Reply-To: <1579706023.93.0.812104912222.issue39421@roundup.psfhosted.org>
Message-ID: <1579793007.94.0.739153535356.issue39421@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39421>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:25:21 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Jan 2020 15:25:21 +0000
Subject: [issue39434] Add float __floordiv__ fast path
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1579793121.99.0.605662407848.issue39434@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So the risk here is that by adding the floordiv fast path, the division code is duplicated, and that increases the risk of accidentally losing the invariant that `a // b` is interchangeable with `divmod(a, b)[0]` (e.g., because someone decides to "fix" the floor float division). That and the usual increased maintenance cost of more code.

Whether the optimization is worth the cost, I'm not sure. My gut feeling is not, but others may have different views.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:29:18 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Jan 2020 15:29:18 +0000
Subject: [issue39434] Add float __floordiv__ fast path
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1579793358.07.0.581636032742.issue39434@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

> (e.g., because someone decides to "fix" the floor float division)

Okay, what if we create a common divmod function except for creating a tuple?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:30:03 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Jan 2020 15:30:03 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579793403.17.0.195882909144.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 99e6c260d60655f3d2885af545cbc220b808d492 by Pablo Galindo in branch 'master':
bpo-17005: Add a class to perform topological sorting to the standard library (GH-11583)
https://github.com/python/cpython/commit/99e6c260d60655f3d2885af545cbc220b808d492


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Thu Jan 23 10:57:13 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Jan 2020 15:57:13 +0000
Subject: [issue39434] Add float __floordiv__ fast path
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1579795033.64.0.160760519072.issue39434@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@mark.dickinson

I extract the common function.
Now maintainence cost is same as AS-IS.

optimization is still work :)

AS-IS: Mean +- std dev: 360 ns +- 19 ns
TO-BE: Mean +- std dev: 185 ns +- 8 ns

what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 23 11:11:01 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Jan 2020 16:11:01 +0000
Subject: [issue39434] Remove unnecessary logic of float __floordiv__
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1579795861.98.0.494258898525.issue39434@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
title: Add float __floordiv__ fast path -> Remove unnecessary logic of float __floordiv__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 23 12:12:19 2020
From: report at bugs.python.org (Guido Imperiale)
Date: Thu, 23 Jan 2020 17:12:19 +0000
Subject: [issue39435] pickle: inconsistent arguments pickle.py vs _pickle.c vs
 docs
Message-ID: <1579799539.42.0.511265830635.issue39435@roundup.psfhosted.org>


New submission from Guido Imperiale <crusaderky at gmail.com>:

(1)
In the documentation for loads(), the name for the first argument of loads is 'bytes_object'. The actual signature, both in pickle.py and _pickle.c, it is instead 'data'.

(2)
In the documentation and in pickle.py, the default value for the 'buffers' parameter is None. However, in _pickle.c, it is an empty tuple (); this is also reflected by running the interpreter:

In [1]: inspect.signature(pickle.loads).parameters['buffers']                                                                                                                                                                                                    
Out[1]: <Parameter "buffers=()">

Thanks to @hauntsaninja for spotting these in https://github.com/python/typeshed/pull/3636

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 360569
nosy: crusaderky, docs at python
priority: normal
severity: normal
status: open
title: pickle: inconsistent arguments pickle.py vs _pickle.c vs docs
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39435>
_______________________________________

From report at bugs.python.org  Thu Jan 23 12:24:58 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 23 Jan 2020 17:24:58 +0000
Subject: [issue39434] Remove unnecessary logic of float __floordiv__
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1579800298.38.0.98349240982.issue39434@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 23 12:51:31 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 23 Jan 2020 17:51:31 +0000
Subject: [issue37444] Differing exception between builtins and importlib when
 importing beyond top-level package
In-Reply-To: <1561749733.32.0.955430999512.issue37444@roundup.psfhosted.org>
Message-ID: <1579801891.63.0.741194011487.issue37444@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Sorry, you're right; I forgot importlib got it "right" while import got it "wrong". :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37444>
_______________________________________

From report at bugs.python.org  Thu Jan 23 12:56:35 2020
From: report at bugs.python.org (Petr Pisl)
Date: Thu, 23 Jan 2020 17:56:35 +0000
Subject: [issue39436] Strange behavior of comparing int and float numbers
Message-ID: <1579802195.37.0.228274815759.issue39436@roundup.psfhosted.org>


New submission from Petr Pisl <petrpisl at gmail.com>:

When python compares float and int created from the same int number should be equal like 

int(1) == float(1)

but from 9007199254740993 this is not true. 

int(9007199254740993) == float(9007199254740993) is not true. The same behavior is for bigger odd numbers. The even numbers are still equal. So it looks like:

int(9007199254740989) == float(9007199254740989) # True
int(9007199254740990) == float(9007199254740990) # True
int(9007199254740991) == float(9007199254740991) # True
int(9007199254740992) == float(9007199254740992) # True
int(9007199254740993) == float(9007199254740993) # False
int(9007199254740994) == float(9007199254740994) # True
int(9007199254740995) == float(9007199254740995) # False
int(9007199254740996) == float(9007199254740996) # True
int(9007199254740997) == float(9007199254740997) # False
int(9007199254740998) == float(9007199254740998) # True

----------
messages: 360571
nosy: Petr Pisl
priority: normal
severity: normal
status: open
title: Strange behavior of comparing int and float numbers
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39436>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:04:23 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2020 18:04:23 +0000
Subject: [issue39431] Mention nonlocal too in assignment quirk
In-Reply-To: <1579779624.25.0.960153197022.issue39431@roundup.psfhosted.org>
Message-ID: <1579802663.46.0.434723462215.issue39431@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> patch review
type:  -> behavior
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39431>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:09:36 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 18:09:36 +0000
Subject: [issue39431] Mention nonlocal too in assignment quirk
In-Reply-To: <1579779624.25.0.960153197022.issue39431@roundup.psfhosted.org>
Message-ID: <1579802976.75.0.978189291285.issue39431@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +17538
pull_request: https://github.com/python/cpython/pull/18152

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39431>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:09:41 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2020 18:09:41 +0000
Subject: [issue39431] Mention nonlocal too in assignment quirk
In-Reply-To: <1579779624.25.0.960153197022.issue39431@roundup.psfhosted.org>
Message-ID: <1579802981.27.0.0162619640404.issue39431@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 7142df5ea23b4ce0efb72746b4b3b65414e8dcb1 by Terry Jan Reedy (Shanavas M) in branch 'master':
bpo-39431: Also mention nonlocal in assignment quirk (GH-17375)
https://github.com/python/cpython/commit/7142df5ea23b4ce0efb72746b4b3b65414e8dcb1


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39431>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:12:47 2020
From: report at bugs.python.org (Dominick Johnson)
Date: Thu, 23 Jan 2020 18:12:47 +0000
Subject: [issue39437] collections.Counter support multiplication
Message-ID: <1579803167.84.0.997525929027.issue39437@roundup.psfhosted.org>


New submission from Dominick Johnson <dominick at techrisdesign.com>:

I would love to see collections.Counter support scalar multiplication.

## My Use Case:

I am writing a python script to manage hardware selections for custom-build computers. Users are able to select various options from a web interface, and the script compiles a list of parts that need purchased.

Each option for user selection has a corresponding Counter object to keep track of what parts are needed for that selection. For example, the user option "i5 Processor" would have a corresponding counter that might looks roughly like this: {"i5-xxxx": 1, "xxxxx Motherboard"}. A user option for "2 TB RAID 10" might have {"1 TB HDD": 4}.

The script adds all the counters for the selected options together to produce a counter detailing the full parts list for the build.

I'd like to add a feature to the script that allows the user to also specify a quantity for certain selections. (Maybe the user wants 2 1TB Storage Drives without any kind of RAID setup). It would be really convenient to be able to simply multiply the selection's counter by it's quantity before adding it to the main counter. e.g. `main_counter += secondary_counter * selection_quantity`

This seems like an extremely simple feature to add, and I would of course be willing to add it myself as long as the Python team is willing to accept a pull request from me adding this feature. However, I've never contributed to such a large project before, so I'm not sure what kind of procedures are in place to make it happen.

----------
components: Library (Lib)
messages: 360573
nosy: Dominick Johnson
priority: normal
severity: normal
status: open
title: collections.Counter support multiplication
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/issue39437>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:15:19 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 18:15:19 +0000
Subject: [issue39431] Mention nonlocal too in assignment quirk
In-Reply-To: <1579779624.25.0.960153197022.issue39431@roundup.psfhosted.org>
Message-ID: <1579803319.77.0.581887945373.issue39431@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0c12d70bfdedf85c62e1c2b8c55ef4e84e6ee461 by Miss Islington (bot) in branch '3.7':
bpo-39431: Also mention nonlocal in assignment quirk (GH-17375)
https://github.com/python/cpython/commit/0c12d70bfdedf85c62e1c2b8c55ef4e84e6ee461


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39431>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:16:53 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 18:16:53 +0000
Subject: [issue39431] Mention nonlocal too in assignment quirk
In-Reply-To: <1579779624.25.0.960153197022.issue39431@roundup.psfhosted.org>
Message-ID: <1579803413.35.0.140376084469.issue39431@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17539
pull_request: https://github.com/python/cpython/pull/18153

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39431>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:22:39 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 18:22:39 +0000
Subject: [issue39431] Mention nonlocal too in assignment quirk
In-Reply-To: <1579779624.25.0.960153197022.issue39431@roundup.psfhosted.org>
Message-ID: <1579803759.77.0.219494448115.issue39431@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5a2356be1a3f4a9b2e509a16062016b7d9dee7e9 by Miss Islington (bot) in branch '3.8':
bpo-39431: Also mention nonlocal in assignment quirk (GH-17375)
https://github.com/python/cpython/commit/5a2356be1a3f4a9b2e509a16062016b7d9dee7e9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39431>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:42:48 2020
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 23 Jan 2020 18:42:48 +0000
Subject: [issue39436] Strange behavior of comparing int and float numbers
In-Reply-To: <1579802195.37.0.228274815759.issue39436@roundup.psfhosted.org>
Message-ID: <1579804968.87.0.106798094892.issue39436@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Python floats have 53 bits of precision, so ints larger than 2**53 will lose their lower bits (assumed to be 0) when converted.

----------
nosy: +mrabarnett
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39436>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:42:53 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 23 Jan 2020 18:42:53 +0000
Subject: [issue39437] collections.Counter support multiplication
In-Reply-To: <1579803167.84.0.997525929027.issue39437@roundup.psfhosted.org>
Message-ID: <1579804973.26.0.376004313974.issue39437@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39437>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:42:59 2020
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 23 Jan 2020 18:42:59 +0000
Subject: [issue39436] Strange behavior of comparing int and float numbers
In-Reply-To: <1579802195.37.0.228274815759.issue39436@roundup.psfhosted.org>
Message-ID: <1579804979.93.0.705160190936.issue39436@roundup.psfhosted.org>


Change by Matthew Barnett <python at mrabarnett.plus.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39436>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:43:26 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 23 Jan 2020 18:43:26 +0000
Subject: [issue39435] pickle: inconsistent arguments pickle.py vs _pickle.c vs
 docs
In-Reply-To: <1579799539.42.0.511265830635.issue39435@roundup.psfhosted.org>
Message-ID: <1579805006.32.0.018311250476.issue39435@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39435>
_______________________________________

From report at bugs.python.org  Thu Jan 23 13:58:56 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2020 18:58:56 +0000
Subject: [issue39431] Mention nonlocal too in assignment quirk
In-Reply-To: <1579779624.25.0.960153197022.issue39431@roundup.psfhosted.org>
Message-ID: <1579805936.46.0.10396504283.issue39431@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39431>
_______________________________________

From report at bugs.python.org  Thu Jan 23 15:19:07 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Jan 2020 20:19:07 +0000
Subject: [issue39426] Pickler docstring misstates default and highest protocols
In-Reply-To: <1579718401.91.0.32620424207.issue39426@roundup.psfhosted.org>
Message-ID: <1579810747.01.0.183926766507.issue39426@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
keywords: +patch
pull_requests: +17540
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18154

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39426>
_______________________________________

From report at bugs.python.org  Thu Jan 23 15:21:35 2020
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 23 Jan 2020 20:21:35 +0000
Subject: [issue39437] collections.Counter support multiplication
In-Reply-To: <1579803167.84.0.997525929027.issue39437@roundup.psfhosted.org>
Message-ID: <1579810895.05.0.889833663311.issue39437@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Duplicate of https://bugs.python.org/issue25478

See Raymond's open PR here: https://github.com/python/cpython/pull/6574

----------
nosy: +ammar2
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Consider adding a normalize() method to collections.Counter()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39437>
_______________________________________

From report at bugs.python.org  Thu Jan 23 15:26:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Jan 2020 20:26:22 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579811182.43.0.348515230356.issue17005@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +17541
pull_request: https://github.com/python/cpython/pull/18155

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Thu Jan 23 15:28:37 2020
From: report at bugs.python.org (Steven G. Johnson)
Date: Thu, 23 Jan 2020 20:28:37 +0000
Subject: [issue39438] better handling of foreign signal handlers in
 signal.signal
Message-ID: <1579811317.28.0.209534127017.issue39438@roundup.psfhosted.org>


New submission from Steven G. Johnson <stevenj.mit at gmail.com>:

In embedded Python, if the embedding code sets a signal handler (e.g. for SIGINT), then signal.getsignal(SIGINT) returns None.   However, signal.signal(SIGINT, signal.getsignal(SIGINT)) throws a TypeError, even though it should logically be a no-op.   This behavior is all implemented in Modules/signalmodule.c and seems to have been around since 2.7 at least.

(Background: We observed this in Julia, which embeds Python in order to call Python code, where matplotlib code that temporarily set signal(SIGINT, SIG_DFL) led to an exception when it tried to restore the original signal handler.  See https://github.com/JuliaPy/PyPlot.jl/issues/459)

The C program below exhibits this problem [it sets its own SIGINT handler and then starts up Python to execute signal(SIGINT,getsignal)].   Running it results in "TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object"

Recommended changes:

1) if Handlers[signalnum].func == NULL, then signal(signalnum, None) should be a no-op, returning None.     This will allow signal(signalnum, getsignal(signalnum)) to always succeed (as a no-op).

2) if Handlers[signalnum].func == NULL, then signal(signalnum, SIG_DFL) should be a no-op, returning None.  That is, the default signal handler should be the foreign signal handler if one is installed.

3) The signal-handling documentation should warn against overriding the signal handler for any signalnum where getsignal(signalnum) returns None (i.e. a foreign signal handler), since there is no way to restore the original signal handler afterwards. Anyway, you should be cautious about overriding signal handlers that don't come from Python.   

test code that throws a TypeError (compile and link with libpython):

#include <Python.h>
#include <signal.h>
#include <stdio.h>
void myhandler(int sig) { printf("got signal %d\n", sig); }
int main(void)
{
    signal(SIGINT, myhandler);
    Py_InitializeEx(0);
    PyRun_SimpleString("import signal\n"
                       "old_signal = signal.getsignal(signal.SIGINT)\n"
                       "signal.signal(signal.SIGINT, old_signal)\n"
                       "print(old_signal)\n");
    Py_Finalize();
    return 0;
}

----------
components: Library (Lib)
messages: 360578
nosy: Steven G. Johnson
priority: normal
severity: normal
status: open
title: better handling of foreign signal handlers in signal.signal
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39438>
_______________________________________

From report at bugs.python.org  Thu Jan 23 15:34:50 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 23 Jan 2020 20:34:50 +0000
Subject: [issue39436] Strange behavior of comparing int and float numbers
In-Reply-To: <1579802195.37.0.228274815759.issue39436@roundup.psfhosted.org>
Message-ID: <1579811690.86.0.108196601799.issue39436@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Further to what Matthew said, this is not just a Python oddity. It applies to just about all programming languages, including C, C++, Java, Javascript, Ruby, etc. Some of them have even less precision by default.

Floats are not the same as the real numbers you learned about in school. There is a huge amount of resources about the limitations of floating point arithmetic on Stackoverflow etc which can be found by googling. A good place to start is the Python FAQs and tutorial:

https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate

https://docs.python.org/3/tutorial/floatingpoint.html#tut-fp-issues

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39436>
_______________________________________

From report at bugs.python.org  Thu Jan 23 16:01:57 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 23 Jan 2020 21:01:57 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1579813317.33.0.549624081405.issue17005@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 65ecc390c1fa5acdd6348ae3f9843bbdcd8870d1 by Pablo Galindo in branch 'master':
bpo-17005: Minor improvements to the documentation of TopologicalSorter (GH-18155)
https://github.com/python/cpython/commit/65ecc390c1fa5acdd6348ae3f9843bbdcd8870d1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17005>
_______________________________________

From report at bugs.python.org  Thu Jan 23 16:04:50 2020
From: report at bugs.python.org (Adam Meily)
Date: Thu, 23 Jan 2020 21:04:50 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
Message-ID: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>


New submission from Adam Meily <meily.adam at gmail.com>:

I upgraded from Python 3.7.1 to 3.7.6 and began noticing a behavior that was breaking my code. My code detects if it's running in a virtualenv. This check worked in 3.7.1 but is broken in 3.7.6.

>From the documentation, sys.prefix and sys.exec_prefix should point to the virtualenv when one is active. However, I'm seeing that both of these constants are pointing to the system installation directory and not my virtualenv when I am in a multiprocessing child. Here is an example output of a test application running in 3.7.6 (I've attached the test script to this ticket):

Parent process
=============================================
sys.prefix:           C:\Users\user\project\venv
sys.exec_prefix:      C:\Users\user\project\venv
sys.base_prefix:      C:\Program Files\Python37
sys.base_exec_prefix: C:\Program Files\Python37
=============================================

Subprocess
=============================================
sys.prefix:           C:\Program Files\Python37
sys.exec_prefix:      C:\Program Files\Python37
sys.base_prefix:      C:\Program Files\Python37
sys.base_exec_prefix: C:\Program Files\Python37
=============================================


I would expect that sys.prefix and sys.exec_prefix to be identical in the parent and child process.

I verified that this behavior is present in 3.7.5, 3.7.6, and 3.8.1. I am on a Windows 10 x64 system.

Python 3.8.1 (tags/v3.8.1:1b293b6, Dec 18 2019, 23:11:46) [MSC v.1916 64 bit (AMD64)] on win32

----------
components: Windows
files: multiproc_venv_prefix.py
messages: 360581
nosy: meilyadam, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Multiprocessing in Virtualenv: sys.prefix is incorrect
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48862/multiproc_venv_prefix.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Thu Jan 23 17:39:03 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 23 Jan 2020 22:39:03 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
In-Reply-To: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>
Message-ID: <1579819143.71.0.794718985867.issue39439@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

This is a duplicate of issue 38092. The required change to fix this is very simple, if you want to work on a PR.

----------
nosy: +eryksun
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> environment variables not passed correctly using new virtualenv launching in windows and python3.7+
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Thu Jan 23 18:00:13 2020
From: report at bugs.python.org (edk)
Date: Thu, 23 Jan 2020 23:00:13 +0000
Subject: [issue39440] Use PyNumber_InPlaceAdd in sum() for the second
 iteration onward
Message-ID: <1579820412.98.0.670054717235.issue39440@roundup.psfhosted.org>


New submission from edk <e at kellett.im>:

The C implementation of sum() contains this comment:

        /* It's tempting to use PyNumber_InPlaceAdd instead of
           PyNumber_Add here, to avoid quadratic running time
           when doing 'sum(list_of_lists, [])'.  However, this
           would produce a change in behaviour: a snippet like
             empty = []
             sum([[x] for x in range(10)], empty)
           would change the value of empty. */

But that doesn't hold after PyNumber_Add has been called once,
because from that point onward the accumulator value is something
we got from an __add__, and the caller can't know if we reuse it.

The in-place version is substantially faster for some workloads--
the example in the comment is an obvious one, but the context in
which I ran into this was using a sum of Counters in a one-liner
a bit like this:

    sum((Counter({line.split("|", 3): len(line)}) for line in sys.stdin), Counter())

in which significant time seems to be spent adding the contents
of the previous accumulator value to the new one.

# before
; ./python -m timeit 'sum(([x] for x in range(1000)), [])'
500 loops, best of 5: 888 usec per loop

# after
; ./python -m timeit 'sum(([x] for x in range(1000)), [])'
5000 loops, best of 5: 65.3 usec per loop


; cat test_.py 
from collections import Counter
import timeit
import random

data = [Counter({random.choice(['foo', 'bar', 'baz', 'qux']): random.randint(1,1000000)}) for _ in range(10000)]

print(min(timeit.repeat('sum(data, Counter())', 'from collections import Counter', number=100, globals={'data': data})))
print(min(timeit.repeat('reduce(Counter.__iadd__, data, Counter())', 'from collections import Counter; from functools import reduce', number=100, globals={'data': data})))

# before
; ./python test_.py
1.8981186050223187
0.7094596439856105

# after
; ./python test_.py 
0.715508968976792
0.7050370009965263

----------
messages: 360583
nosy: edk
priority: normal
severity: normal
status: open
title: Use PyNumber_InPlaceAdd in sum() for the second iteration onward
type: performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39440>
_______________________________________

From report at bugs.python.org  Thu Jan 23 18:31:42 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 23:31:42 +0000
Subject: [issue35182] Popen.communicate() breaks when child closes its side of
 pipe but not exits
In-Reply-To: <1541586210.62.0.788709270274.issue35182@psf.upfronthosting.co.za>
Message-ID: <1579822302.18.0.69139372608.issue35182@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5654f83b9706af88040f515791f1cdc5d81cd9d6 by Miss Islington (bot) (Alex Rebert) in branch '3.8':
[3.8] bpo-35182: fix communicate() crash after child closes its pipes (GH-18117) (GH-18148)
https://github.com/python/cpython/commit/5654f83b9706af88040f515791f1cdc5d81cd9d6


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35182>
_______________________________________

From report at bugs.python.org  Thu Jan 23 18:32:35 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 23 Jan 2020 23:32:35 +0000
Subject: [issue35182] Popen.communicate() breaks when child closes its side of
 pipe but not exits
In-Reply-To: <1541586210.62.0.788709270274.issue35182@psf.upfronthosting.co.za>
Message-ID: <1579822355.03.0.092189590016.issue35182@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 61b3484cdf27ceca1c1069a351487d2db4b2b48c by Miss Islington (bot) (Alex Rebert) in branch '3.7':
[3.7] bpo-35182: fix communicate() crash after child closes its pipes (GH-18117) (GH-18151)
https://github.com/python/cpython/commit/61b3484cdf27ceca1c1069a351487d2db4b2b48c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35182>
_______________________________________

From report at bugs.python.org  Thu Jan 23 18:33:29 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 23 Jan 2020 23:33:29 +0000
Subject: [issue35182] Popen.communicate() breaks when child closes its side of
 pipe but not exits
In-Reply-To: <1541586210.62.0.788709270274.issue35182@psf.upfronthosting.co.za>
Message-ID: <1579822409.33.0.453933591955.issue35182@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

thanks everyone!

----------
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35182>
_______________________________________

From report at bugs.python.org  Thu Jan 23 19:00:01 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 24 Jan 2020 00:00:01 +0000
Subject: [issue39440] Use PyNumber_InPlaceAdd in sum() for the second
 iteration onward
In-Reply-To: <1579820412.98.0.670054717235.issue39440@roundup.psfhosted.org>
Message-ID: <1579824001.98.0.525058711212.issue39440@roundup.psfhosted.org>


Change by Ammar Askar <ammar at ammaraskar.com>:


----------
keywords: +patch
pull_requests: +17542
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18156

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39440>
_______________________________________

From report at bugs.python.org  Thu Jan 23 19:10:14 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 24 Jan 2020 00:10:14 +0000
Subject: [issue39440] Use PyNumber_InPlaceAdd in sum() for the second
 iteration onward
In-Reply-To: <1579820412.98.0.670054717235.issue39440@roundup.psfhosted.org>
Message-ID: <1579824614.93.0.815684572929.issue39440@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Prior discussion at https://bugs.python.org/issue18305. Note the final comment.

In short, this is a breaking semantic change, and the general consensus is that using sum for sequence concatenation is an anti-pattern.

----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39440>
_______________________________________

From report at bugs.python.org  Thu Jan 23 19:20:01 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 24 Jan 2020 00:20:01 +0000
Subject: [issue39440] Use PyNumber_InPlaceAdd in sum() for the second
 iteration onward
In-Reply-To: <1579820412.98.0.670054717235.issue39440@roundup.psfhosted.org>
Message-ID: <1579825201.14.0.103292017855.issue39440@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39440>
_______________________________________

From report at bugs.python.org  Thu Jan 23 19:23:00 2020
From: report at bugs.python.org (edk)
Date: Fri, 24 Jan 2020 00:23:00 +0000
Subject: [issue39440] Use PyNumber_InPlaceAdd in sum() for the second
 iteration onward
In-Reply-To: <1579820412.98.0.670054717235.issue39440@roundup.psfhosted.org>
Message-ID: <1579825380.38.0.790753408204.issue39440@roundup.psfhosted.org>


edk <e at kellett.im> added the comment:

It's not only sequences. But I didn't know this had come up before, sorry. Maybe the nature of the warning in the source code s a bit misleading?

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39440>
_______________________________________

From report at bugs.python.org  Thu Jan 23 20:25:06 2020
From: report at bugs.python.org (Adam Meily)
Date: Fri, 24 Jan 2020 01:25:06 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
In-Reply-To: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>
Message-ID: <1579829106.08.0.894852975245.issue39439@roundup.psfhosted.org>


Adam Meily <meily.adam at gmail.com> added the comment:

OK, that makes sense.

For 3.7, I can create a PR for that corrects the order of arguments passed into _winapi.CreateProcess

For 3.8 / master, the problem appears to be that the check in popen_spawn_win32.py to set the subprocess env is failing because sys.executable != spawn.get_executable() -- spawn.get_executable() is returning sys._base_executable. So, can you confirm that the fix is to just change spawn.get_executable() to return sys.executable, like it was prior to the PR mentioned in the other ticket?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Thu Jan 23 20:54:21 2020
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 24 Jan 2020 01:54:21 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
In-Reply-To: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>
Message-ID: <1579830861.59.0.321868019044.issue39439@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> can you confirm that the fix is to just change spawn.get_executable() 
> to return sys.executable, like it was prior to the PR mentioned in 
> the other ticket?

Yes, in spawn.py, change `_python_exe = sys._base_executable` to `_python_exe = sys.executable`. This is the value that gets returned by spawn.get_executable().

This will restore the operation of the following code in Popen.__init__ in popen_spawn_win32.py:

        python_exe = spawn.get_executable()

        # bpo-35797: When running in a venv, we bypass the redirect
        # executor and launch our base Python.
        if WINENV and _path_eq(python_exe, sys.executable):
            python_exe = sys._base_executable
            env = os.environ.copy()
            env["__PYVENV_LAUNCHER__"] = sys.executable

This code switches to running the base executable in a virtual environment, which is required in order to support duplicating handles to the child or stealing handles from the parent. And the startup code in the child process is made aware of virtual environment via the "__PYVENV_LAUNCHER__" environment variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Thu Jan 23 22:06:24 2020
From: report at bugs.python.org (Adam Meily)
Date: Fri, 24 Jan 2020 03:06:24 +0000
Subject: [issue38092] environment variables not passed correctly using new
 virtualenv launching in windows and python3.7+
In-Reply-To: <1568122359.92.0.800539114246.issue38092@roundup.psfhosted.org>
Message-ID: <1579835184.53.0.263461998445.issue38092@roundup.psfhosted.org>


Change by Adam Meily <meily.adam at gmail.com>:


----------
pull_requests: +17543
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18157

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38092>
_______________________________________

From report at bugs.python.org  Thu Jan 23 22:06:24 2020
From: report at bugs.python.org (Adam Meily)
Date: Fri, 24 Jan 2020 03:06:24 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
In-Reply-To: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>
Message-ID: <1579835184.67.0.0456131915764.issue39439@roundup.psfhosted.org>


Change by Adam Meily <meily.adam at gmail.com>:


----------
pull_requests: +17544
pull_request: https://github.com/python/cpython/pull/18157

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Thu Jan 23 22:14:37 2020
From: report at bugs.python.org (Adam Meily)
Date: Fri, 24 Jan 2020 03:14:37 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
In-Reply-To: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>
Message-ID: <1579835677.23.0.503391809433.issue39439@roundup.psfhosted.org>


Change by Adam Meily <meily.adam at gmail.com>:


----------
pull_requests: +17545
pull_request: https://github.com/python/cpython/pull/18158

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Thu Jan 23 22:17:00 2020
From: report at bugs.python.org (Adam Meily)
Date: Fri, 24 Jan 2020 03:17:00 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
In-Reply-To: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>
Message-ID: <1579835820.02.0.9859936016.issue39439@roundup.psfhosted.org>


Change by Adam Meily <meily.adam at gmail.com>:


----------
pull_requests: +17546
pull_request: https://github.com/python/cpython/pull/18159

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Fri Jan 24 00:19:56 2020
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 24 Jan 2020 05:19:56 +0000
Subject: [issue39435] pickle: inconsistent arguments pickle.py vs _pickle.c vs
 docs
In-Reply-To: <1579799539.42.0.511265830635.issue39435@roundup.psfhosted.org>
Message-ID: <1579843196.99.0.447241172641.issue39435@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17547
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18160

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39435>
_______________________________________

From report at bugs.python.org  Fri Jan 24 03:13:41 2020
From: report at bugs.python.org (Chris Withers)
Date: Fri, 24 Jan 2020 08:13:41 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1579853621.21.0.230464265598.issue24928@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

As I said before, I can't see an additional test like this hurting, especially if it highlights problems with earlier python versions when it's backported.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Fri Jan 24 03:14:25 2020
From: report at bugs.python.org (Chris Withers)
Date: Fri, 24 Jan 2020 08:14:25 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1579853665.74.0.605347194613.issue24928@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 1d0c5e16eab29d55773cc4196bb90d2bf12e09dd by Chris Withers (Emmanuel Arias) in branch 'master':
bpo-24928: Add test case for patch.dict using OrderedDict (GH -11437)
https://github.com/python/cpython/commit/1d0c5e16eab29d55773cc4196bb90d2bf12e09dd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Fri Jan 24 03:20:31 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 24 Jan 2020 08:20:31 +0000
Subject: [issue39391] Nondeterministic Pydoc output on functions that have
 functions as default parameters
In-Reply-To: <1579475037.48.0.632958566945.issue39391@roundup.psfhosted.org>
Message-ID: <1579854031.99.0.161955150526.issue39391@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

See also: https://bugs.python.org/issue37645 which discusses changing the string representation of functions to omit the address.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39391>
_______________________________________

From report at bugs.python.org  Fri Jan 24 03:26:24 2020
From: report at bugs.python.org (Chris Withers)
Date: Fri, 24 Jan 2020 08:26:24 +0000
Subject: [issue37669] Make mock_open return per-file content
In-Reply-To: <1563972418.64.0.300779941937.issue37669@roundup.psfhosted.org>
Message-ID: <1579854384.23.0.872716462256.issue37669@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

I'm not sure I like the API feel after this change: two parameters that can't be used at the same time.

As Karthikeyan points out, this can be achieved using side_effect. Personally, I'd prefer a PR that adds a unit test showing that this approach works, and an example included in the docs as suggested above.

Also, be aware that there can be better options for mocking files. https://github.com/jmcgeheeiv/pyfakefs/ and https://docs.pytest.org/en/latest/tmpdir.html would be my recommendation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37669>
_______________________________________

From report at bugs.python.org  Fri Jan 24 03:28:39 2020
From: report at bugs.python.org (Chris Withers)
Date: Fri, 24 Jan 2020 08:28:39 +0000
Subject: [issue37669] Make mock_open return per-file content
In-Reply-To: <1563972418.64.0.300779941937.issue37669@roundup.psfhosted.org>
Message-ID: <1579854519.73.0.428741418738.issue37669@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

Closing in favour of issue38157.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37669>
_______________________________________

From report at bugs.python.org  Fri Jan 24 03:41:44 2020
From: report at bugs.python.org (Chris Withers)
Date: Fri, 24 Jan 2020 08:41:44 +0000
Subject: [issue21600] mock.patch.stopall doesn't work with patch.dict
In-Reply-To: <1401334528.48.0.358693350259.issue21600@psf.upfronthosting.co.za>
Message-ID: <1579855304.52.0.568479831356.issue21600@roundup.psfhosted.org>


Change by Chris Withers <chris at withers.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21600>
_______________________________________

From report at bugs.python.org  Fri Jan 24 03:51:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jan 2020 08:51:13 +0000
Subject: [issue39433] curses.setupterm can raise _curses.error
In-Reply-To: <1579787839.53.0.046587762459.issue39433@roundup.psfhosted.org>
Message-ID: <1579855873.48.3.1114573088e-06.issue39433@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

curses.error is documented as an exception raised when a curses library function returns an error. No need to repeat this for every curses function.

It is very uncommon to document all exceptions that can be raised by a particular function in Python. Because of dynamic nature of Python virtually any function can raise arbitrary exception.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39433>
_______________________________________

From report at bugs.python.org  Fri Jan 24 03:57:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 08:57:53 +0000
Subject: [issue39420] Windows: convertenviron() doesn't parse environment
 variables properly
In-Reply-To: <1579705819.39.0.675106611885.issue39420@roundup.psfhosted.org>
Message-ID: <1579856273.15.0.572376855746.issue39420@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

You're right, Windows works as expected. I close the issue.

See https://github.com/python/cpython/pull/18115 for more information.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39420>
_______________________________________

From report at bugs.python.org  Fri Jan 24 04:06:33 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jan 2020 09:06:33 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579856793.97.0.798289646725.issue39430@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +17548
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18161

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 04:14:16 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jan 2020 09:14:16 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579857256.4.0.695438059543.issue39430@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 18161 fixes race condition by using "from ... import ..." which waits until the module be completely initialized if the specified names are not set.

----------
components: +Library (Lib)
nosy: +serhiy.storchaka
type: crash -> behavior
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 04:14:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jan 2020 09:14:45 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579857285.12.0.185429156354.issue39430@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +brett.cannon, eric.snow, lars.gustaebel, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 04:22:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 09:22:21 +0000
Subject: [issue39429] Add a new "Python Development Mode" page to the
 documentation
In-Reply-To: <1579741396.58.0.897370884771.issue39429@roundup.psfhosted.org>
Message-ID: <1579857741.64.0.453882162804.issue39429@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b9783d2e035d2babe8fcd9ec109044c0002c18a2 by Victor Stinner in branch 'master':
bpo-39429: Add a new "Python Development Mode" doc page (GH-18132)
https://github.com/python/cpython/commit/b9783d2e035d2babe8fcd9ec109044c0002c18a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39429>
_______________________________________

From report at bugs.python.org  Fri Jan 24 04:22:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 09:22:45 +0000
Subject: [issue39429] Add a new "Python Development Mode" page to the
 documentation
In-Reply-To: <1579741396.58.0.897370884771.issue39429@roundup.psfhosted.org>
Message-ID: <1579857765.35.0.182674618461.issue39429@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39429>
_______________________________________

From report at bugs.python.org  Fri Jan 24 04:24:59 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jan 2020 09:24:59 +0000
Subject: [issue39391] Nondeterministic Pydoc output on functions that have
 functions as default parameters
In-Reply-To: <1579475037.48.0.632958566945.issue39391@roundup.psfhosted.org>
Message-ID: <1579857899.14.0.406289223806.issue39391@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

You will get the same problem for common idiom of using a singleton for optional parameters without default value.

    _singleton = object()
    def get(key, default=_signleton):
        if default is _signleton:
            ...

And for other objects whos repr contains "at 0x...".

And even more complex problem with sets.

When test the pydoc output, ignore non-deterministic parts. For example, doctest allows you to use a placeholder.

   >>> C() #doctest: +ELLIPSIS
   <__main__.C instance at 0x...>

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39391>
_______________________________________

From report at bugs.python.org  Fri Jan 24 04:50:19 2020
From: report at bugs.python.org (=?utf-8?q?Gu=C3=A9na=C3=ABl_Muller?=)
Date: Fri, 24 Jan 2020 09:50:19 +0000
Subject: [issue39441] mimetypes.guess_extension unable to get non-lowercase
 mimetype
Message-ID: <1579859419.07.0.145257790189.issue39441@roundup.psfhosted.org>


New submission from Gu?na?l Muller <inkey at inkey-art.net>:

mimetypes.guess_extension and mimetypes.guess_all_extensions doesn't work correctly with non-lowercase mimetype.


>>> import mimetypes
>>> mimetypes.guess_type('file.pptm')
('application/vnd.ms-powerpoint.presentation.macroEnabled.12', None)
>>> mimetypes.guess_extension("application/vnd.ms powerpoint.presentation.macroEnabled.12")

>>>

This issue exist because we automatically convert type as lower in guess_all_extensions, but we do not prevent added type to be lowercase.

----------
messages: 360601
nosy: Inkhey
priority: normal
severity: normal
status: open
title: mimetypes.guess_extension unable to get non-lowercase mimetype
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/issue39441>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:03:26 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Jan 2020 10:03:26 +0000
Subject: [issue39426] Pickler docstring misstates default and highest protocols
In-Reply-To: <1579718401.91.0.32620424207.issue39426@roundup.psfhosted.org>
Message-ID: <1579860206.4.0.905438939064.issue39426@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e9652e8d58392f5022759ba06b444ce970eb12db by Miss Islington (bot) (Mark Dickinson) in branch 'master':
bpo-39426: Fix outdated default and highest protocols in docs (GH-18154)
https://github.com/python/cpython/commit/e9652e8d58392f5022759ba06b444ce970eb12db


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39426>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:03:46 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Jan 2020 10:03:46 +0000
Subject: [issue39426] Pickler docstring misstates default and highest protocols
In-Reply-To: <1579718401.91.0.32620424207.issue39426@roundup.psfhosted.org>
Message-ID: <1579860225.99.0.650903012727.issue39426@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17549
pull_request: https://github.com/python/cpython/pull/18162

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39426>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:08:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 10:08:03 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579860483.61.0.779011202176.issue39413@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17550
pull_request: https://github.com/python/cpython/pull/18163

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:11:36 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Jan 2020 10:11:36 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579860696.59.0.593251739703.issue39430@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:20:38 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Jan 2020 10:20:38 +0000
Subject: [issue39426] Pickler docstring misstates default and highest protocols
In-Reply-To: <1579718401.91.0.32620424207.issue39426@roundup.psfhosted.org>
Message-ID: <1579861238.95.0.346806242913.issue39426@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a46728a570e30e88df253eab17ad6c4372a422da by Miss Islington (bot) in branch '3.8':
bpo-39426: Fix outdated default and highest protocols in docs (GH-18154)
https://github.com/python/cpython/commit/a46728a570e30e88df253eab17ad6c4372a422da


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39426>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:23:02 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Jan 2020 10:23:02 +0000
Subject: [issue39426] Pickler docstring misstates default and highest protocols
In-Reply-To: <1579718401.91.0.32620424207.issue39426@roundup.psfhosted.org>
Message-ID: <1579861382.51.0.971627752418.issue39426@roundup.psfhosted.org>


Change by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39426>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:27:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 10:27:17 +0000
Subject: [issue39398] AMD64 Fedora Rawhide Clang 3.x: C compiler cannot create
 executables
In-Reply-To: <1579540465.66.0.318494432862.issue39398@roundup.psfhosted.org>
Message-ID: <1579861637.04.0.338144653788.issue39398@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Charalampos downgraded clang to 10.0.0 to workaround the issue. The buildbot worker compiles the code succesfully again:
https://buildbot.python.org/all/#/builders/169

I close the issue. The issue is now tracked in Fedora Rawhide anyway:
https://src.fedoraproject.org/rpms/compiler-rt/pull-request/10

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39398>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:29:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 10:29:36 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579861776.5.0.621955565841.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Building and verifying the checksum in "RTA protocol" that uses this: (...)

Are you simply asking to not deprecate binascii.crc_hqx()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:31:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 10:31:52 +0000
Subject: [issue39035] Travis CI fail on backports: pyvenv not installed
In-Reply-To: <1576232931.72.0.607976145841.issue39035@roundup.psfhosted.org>
Message-ID: <1579861912.63.0.0191205654514.issue39035@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't notice the error in the last days, so I close the issue.

I would be nice to merge PR 17623, but that can be done later (by Larry Hastings, the 3.5 release manager).

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39035>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:35:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 10:35:07 +0000
Subject: [issue39361] [C API] Document PyTypeObject.tp_print removal in What's
 New In Python 3.9
In-Reply-To: <1579182449.25.0.646688097362.issue39361@roundup.psfhosted.org>
Message-ID: <1579862107.94.0.00907191815917.issue39361@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 2d5097663d7f80921fb07cdcd26c9d59cf71f1a2 by Victor Stinner (Ammar Askar) in branch 'master':
bpo-39361: Document the removal of PyTypeObject.tp_print (GH-18125)
https://github.com/python/cpython/commit/2d5097663d7f80921fb07cdcd26c9d59cf71f1a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39361>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:35:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 10:35:36 +0000
Subject: [issue39361] [C API] Document PyTypeObject.tp_print removal in What's
 New In Python 3.9
In-Reply-To: <1579182449.25.0.646688097362.issue39361@roundup.psfhosted.org>
Message-ID: <1579862136.43.0.866054250717.issue39361@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39361>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:42:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 10:42:07 +0000
Subject: [issue38691] [easy] importlib: PYTHONCASEOK should be ignored when
 using python3 -E
In-Reply-To: <1572918956.02.0.914904783167.issue38691@roundup.psfhosted.org>
Message-ID: <1579862527.75.0.312274570967.issue38691@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

sys.flags.ignore_environment should be used.

----------
keywords: +newcomer friendly
title: importlib: PYTHONCASEOK should be ignored when using python3 -E -> [easy] importlib: PYTHONCASEOK should be ignored when using python3 -E

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38691>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:42:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 10:42:20 +0000
Subject: [issue39424] [easy] test_signal: test_pidfd_send_signal() uses
 deprecated assertRaisesRegexp() method
In-Reply-To: <1579712181.32.0.0974422649306.issue39424@roundup.psfhosted.org>
Message-ID: <1579862540.78.0.150131569556.issue39424@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: test_signal: test_pidfd_send_signal() uses deprecated assertRaisesRegexp() method -> [easy] test_signal: test_pidfd_send_signal() uses deprecated assertRaisesRegexp() method

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39424>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:53:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 10:53:48 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1579863228.49.0.906981163339.issue39413@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 161e7b36b1ea871a1352ccfc1d4f4c1eda76830f by Victor Stinner in branch 'master':
bpo-39413: Implement os.unsetenv() on Windows (GH-18163)
https://github.com/python/cpython/commit/161e7b36b1ea871a1352ccfc1d4f4c1eda76830f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Fri Jan 24 05:54:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 10:54:53 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1579863293.18.0.111013575355.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17551
pull_request: https://github.com/python/cpython/pull/18164

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Fri Jan 24 06:12:30 2020
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 24 Jan 2020 11:12:30 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
In-Reply-To: <1579776260.84.0.333075912412.issue39380@roundup.psfhosted.org>
Message-ID: <1579864350.54.0.227205277859.issue39380@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Can we have some deprecation period?

def __init__(self, ..., encoding=None):
    ...
    if encoding is not None:
        self.encoding = encoding
    else:
        warnings.warn("The default encoding of the FTP class will be changed from 'latin1' to 'utf-8' in 3.11. Pass the encoding explicitly for now.",
            DeprecationWarning)

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Fri Jan 24 06:48:40 2020
From: report at bugs.python.org (=?utf-8?q?Wojciech_=C5=81opata?=)
Date: Fri, 24 Jan 2020 11:48:40 +0000
Subject: [issue39442] from __future__ import annotations breaks
 dataclasses.Field.type
Message-ID: <1579866520.75.0.652812484582.issue39442@roundup.psfhosted.org>


New submission from Wojciech ?opata <wlopata at gmail.com>:

I've checked this behaviour under Python 3.7.5 and 3.8.1.

```
from __future__ import annotations
from dataclasses import dataclass, fields

@dataclass
class Foo:
    x: int

print(fields(Foo)[0].type)
```

With annotations imported, the `type` field of Field class becomes a string with a name of a type, and the program outputs 'int'.

Without annotations, the `type` field of Field class is a type, and the program outputs <class 'int'>.

I found this out when using dataclasses_serialization module. Following code works fine when we remove import of annotations:

```
from __future__ import annotations
from dataclasses import dataclass
from dataclasses_serialization.json import JSONSerializer

@dataclass
class Foo:
    x: int

JSONSerializer.deserialize(Foo, {'x': 42})
```

TypeError: issubclass() arg 1 must be a class

----------
components: Library (Lib)
messages: 360611
nosy: lopek
priority: normal
severity: normal
status: open
title: from __future__ import annotations breaks dataclasses.Field.type
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39442>
_______________________________________

From report at bugs.python.org  Fri Jan 24 06:49:56 2020
From: report at bugs.python.org (=?utf-8?q?Wojciech_=C5=81opata?=)
Date: Fri, 24 Jan 2020 11:49:56 +0000
Subject: [issue39442] from __future__ import annotations makes
 dataclasses.Field.type a string, not type
In-Reply-To: <1579866520.75.0.652812484582.issue39442@roundup.psfhosted.org>
Message-ID: <1579866596.43.0.376159611424.issue39442@roundup.psfhosted.org>


Change by Wojciech ?opata <wlopata at gmail.com>:


----------
title: from __future__ import annotations breaks dataclasses.Field.type -> from __future__ import annotations makes dataclasses.Field.type a string, not type

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39442>
_______________________________________

From report at bugs.python.org  Fri Jan 24 06:58:40 2020
From: report at bugs.python.org (Michael Felt)
Date: Fri, 24 Jan 2020 11:58:40 +0000
Subject: [issue39409] AIX: FAIL: test_specific_values
 (test.test_cmath.CMathTests)
In-Reply-To: <1579605816.87.0.587336321661.issue39409@roundup.psfhosted.org>
Message-ID: <1579867120.4.0.290993219617.issue39409@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I am looking at this, as/when I can. Was hoping for a ancient school option to have the compiler stop with assembly code generation ipv objdump. However, I have not been successful there.

Found objdump, and I'll work from that - and also do some of the tests from the closed issues suggested.

Also, noticed that at least one AIX bot turned green again (23-01-2020), so I'll have to look into what else has changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39409>
_______________________________________

From report at bugs.python.org  Fri Jan 24 07:01:19 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Jan 2020 12:01:19 +0000
Subject: [issue39442] from __future__ import annotations makes
 dataclasses.Field.type a string, not type
In-Reply-To: <1579866520.75.0.652812484582.issue39442@roundup.psfhosted.org>
Message-ID: <1579867279.7.0.939857715242.issue39442@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39442>
_______________________________________

From report at bugs.python.org  Fri Jan 24 07:31:24 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 24 Jan 2020 12:31:24 +0000
Subject: [issue39442] from __future__ import annotations makes
 dataclasses.Field.type a string, not type
In-Reply-To: <1579866520.75.0.652812484582.issue39442@roundup.psfhosted.org>
Message-ID: <1579869084.02.0.524089753512.issue39442@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Isn't that the entire point of "from __future__ import annotations"?

Also, please show the traceback when reporting errors so that I can see what's going on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39442>
_______________________________________

From report at bugs.python.org  Fri Jan 24 08:05:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 13:05:51 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579871151.79.0.691623417294.issue39395@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b8d1262e8afe7b907b4a394a191739571092acdb by Victor Stinner in branch 'master':
bpo-39395: putenv() and unsetenv() always available (GH-18135)
https://github.com/python/cpython/commit/b8d1262e8afe7b907b4a394a191739571092acdb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Fri Jan 24 08:12:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 13:12:09 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579871529.3.0.283020802778.issue39395@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

On non-Windows platforms, Python now requires setenv() and unsetenv()
functions to build.

setenv() and unsetenv() should be available on all platforms supported by Python. If it's not the case, someone can maintain a downstream patch which is a revert of commit b8d1262e8afe7b907b4a394a191739571092acdb.

If someone asks to support a platform which doesn't provide setenv() and unsetenv(), we can revisit the idea of unsetting variables set by Python at exit, to workaround putenv() issue: something like my (abandonned) PR 18078.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Fri Jan 24 08:12:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 13:12:45 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579871565.27.0.65374199099.issue39395@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Fri Jan 24 08:14:33 2020
From: report at bugs.python.org (Chris Withers)
Date: Fri, 24 Jan 2020 13:14:33 +0000
Subject: [issue38473] AttributeError on asserting autospecced mock object
 added using attach_mock
In-Reply-To: <1571063109.86.0.136370910863.issue38473@roundup.psfhosted.org>
Message-ID: <1579871673.78.0.827746422722.issue38473@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 66b00a9d3aacf6ed49412f48743e4913104a2bb3 by Chris Withers (Karthikeyan Singaravelan) in branch 'master':
bpo-38473: Handle autospecced functions and methods used with attach_mock (GH-16784)
https://github.com/python/cpython/commit/66b00a9d3aacf6ed49412f48743e4913104a2bb3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38473>
_______________________________________

From report at bugs.python.org  Fri Jan 24 08:18:59 2020
From: report at bugs.python.org (=?utf-8?q?Wojciech_=C5=81opata?=)
Date: Fri, 24 Jan 2020 13:18:59 +0000
Subject: [issue39442] from __future__ import annotations makes
 dataclasses.Field.type a string, not type
In-Reply-To: <1579866520.75.0.652812484582.issue39442@roundup.psfhosted.org>
Message-ID: <1579871939.69.0.920900049209.issue39442@roundup.psfhosted.org>


Wojciech ?opata <wlopata at gmail.com> added the comment:

> Isn't that the entire point of "from __future__ import annotations"?
I'm not complaining about Foo.__annotations__ storing strings instead of types. I'm complaining about dataclass.Field.type being a string instead of type. I don't think the former needs to imply the latter. I'm trying to access Field objects at runtime, when it should already be possible to resolve the types, as far as I understand.


> Also, please show the traceback when reporting errors so that I can see what's going on.

That's the error I get trying to use dataclasses_serialization module:

$ cat test.py 
from __future__ import annotations
from dataclasses import dataclass
from dataclasses_serialization.json import JSONSerializer

@dataclass
class Foo:
    x: int

JSONSerializer.deserialize(Foo, {'x': 42})
$ python3 test.py 
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py", line 125, in dict_to_dataclass
    for fld, fld_type in zip(flds, fld_types)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py", line 126, in <dictcomp>
    if fld.name in dct
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/toolz/functoolz.py", line 303, in __call__
    return self._partial(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py", line 234, in deserialize
    if issubclass(cls, type_):
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py", line 72, in issubclass
    return original_issubclass(cls, classinfo)
TypeError: issubclass() arg 1 must be a class

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test.py", line 9, in <module>
    JSONSerializer.deserialize(Foo, {'x': 42})
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/toolz/functoolz.py", line 303, in __call__
    return self._partial(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py", line 238, in deserialize
    return self.deserialization_functions[dataclass](cls, serialized_obj)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/toolz/functoolz.py", line 303, in __call__
    return self._partial(*args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/dataclasses_serialization/serializer_base.py", line 131, in dict_to_dataclass
    cls
dataclasses_serialization.serializer_base.DeserializationError: Missing one or more required fields to deserialize {'x': 42} as <class '__main__.Foo'>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39442>
_______________________________________

From report at bugs.python.org  Fri Jan 24 08:20:56 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Jan 2020 13:20:56 +0000
Subject: [issue38473] AttributeError on asserting autospecced mock object
 added using attach_mock
In-Reply-To: <1571063109.86.0.136370910863.issue38473@roundup.psfhosted.org>
Message-ID: <1579872056.86.0.239286641233.issue38473@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17552
pull_request: https://github.com/python/cpython/pull/18166

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38473>
_______________________________________

From report at bugs.python.org  Fri Jan 24 08:21:04 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Jan 2020 13:21:04 +0000
Subject: [issue38473] AttributeError on asserting autospecced mock object
 added using attach_mock
In-Reply-To: <1571063109.86.0.136370910863.issue38473@roundup.psfhosted.org>
Message-ID: <1579872064.03.0.199266323483.issue38473@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17553
pull_request: https://github.com/python/cpython/pull/18167

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38473>
_______________________________________

From report at bugs.python.org  Fri Jan 24 08:33:43 2020
From: report at bugs.python.org (Maciej Gol)
Date: Fri, 24 Jan 2020 13:33:43 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579872823.18.0.663006882195.issue39430@roundup.psfhosted.org>


Maciej Gol <maciej.gol at curo.ch> added the comment:

> PR 18161 fixes race condition by using "from ... import ..."
> which waits until the module be completely initialized if the specified
> names are not set.

Correct me if I'm wrong, but I think the behavior of 'import lzma' in
this case (vulnerable to race conditions) is not as intended? Shouldn't we also fix
the 'import' statement itself?

In general, I understand that due to how dynamic Python is, it might not be
possible to load every single name at import time using `import` and using
`from x import y` brings more determinism (because we have a safeguard now).

But, looking at the stacktrace from ipython the problem lies in a sequence of
import statements, not dynamic python coding. Shouldn't the importing mechanism
be more deterministic in such case? For sure, it should not return an empty module
(this is the case when race condition occurs).

I think a race condition caused by simply using `import` statements
(not `from x import y`) is a big caveat in the statement itself and how python
imports work.

Haven't checked if the cause is isolated to how tarfile works, or works in general, though :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 08:34:09 2020
From: report at bugs.python.org (Maciej Gol)
Date: Fri, 24 Jan 2020 13:34:09 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579872849.57.0.298226334465.issue39430@roundup.psfhosted.org>


Maciej Gol <maciej.gol at curo.ch> added the comment:

By the way, thanks a lot for the fix <3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 09:08:24 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jan 2020 14:08:24 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579874904.2.0.992346888571.issue39430@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is intended to support circular imports. Let foo.py contains "import bar" and bar.py contains "import foo". When you execute "import foo", the import machinery first creates an empty module foo, adds it to sys.modules, reads foo.py and executes it in the namespace of module foo. When the interpreter encounters "import bar" in foo.py, the import machinery creates an empty module bar, adds it to sys.modules, reads bar.py and executes it in the namespace of module bar. When the interpreter encounters "import foo" in bar.py, the import machinery takes the module foo from sys.modules. So you break an infinite cycle and can import modules with cyclic dependencies.

You can argue that cyclic import does not look as a good practice, but actually it is pretty common case when you import a submodule in a package. If foo/__init__.py contains "from .bar import Bar", the foo module must be imported before you import foo.bar, but is not completely initialized at that time yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 09:51:25 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 24 Jan 2020 14:51:25 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579877485.57.0.803296583038.issue39390@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:


New changeset 88704334e5262c6cd395a0809d4ef810f33f3ca5 by Giampaolo Rodola (mbarkhau) in branch 'master':
bpo-39390 shutil: fix argument types for ignore callback (GH-18122)
https://github.com/python/cpython/commit/88704334e5262c6cd395a0809d4ef810f33f3ca5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Fri Jan 24 09:59:56 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 24 Jan 2020 14:59:56 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579877996.1.0.886963511133.issue39390@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

For completeness, a similar problem is present also on python < 3.8 if passing a pathlib.Path type as *src*: the callback function will receive a pathlib.Path type once, and then string types.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Fri Jan 24 10:17:34 2020
From: report at bugs.python.org (Hugo Ricateau)
Date: Fri, 24 Jan 2020 15:17:34 +0000
Subject: [issue39443] Inhomogeneous behaviour for descriptors in between the
 class-instance and metaclass-class pairs
Message-ID: <1579879054.45.0.122838509696.issue39443@roundup.psfhosted.org>


New submission from Hugo Ricateau <hugo.ricateau at gmail.com>:

Assume one has defined the following descriptor:
```
class Descriptor:
    def __set__(self, instance, value):
        print('SET')
```

On the one hand, for the class-instance pair, the behaviour is as follows:
```
class FirstClass:
    descriptor = Descriptor()

    def __init__(self):
        self.descriptor = None

FirstClass().descriptor = None
```
results in "SET" being displayed twice; i.e. both assignations triggered the __set__ method of the descriptor.

On the other hand, for the metaclass-class pair, the behaviour is the following:
```
class SecondClassMeta(type):
    descriptor = Descriptor()

class SecondClass(metaclass=SecondClassMeta):
    descriptor = None

SecondClass.descriptor = None
```
results in "SET" being displayed only once: the first assignation (the one in the class definition) did not triggered __set__.

It looks to me like an undesirable asymmetry between the descriptors behaviour when in classes vs when in metaclasses. Is that intended? If it is, I think it should be highlighted in the descriptors documentation.

Best

----------
components: Interpreter Core
messages: 360623
nosy: Hugo Ricateau
priority: normal
severity: normal
status: open
title: Inhomogeneous behaviour for descriptors in between the class-instance and metaclass-class pairs
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39443>
_______________________________________

From report at bugs.python.org  Fri Jan 24 10:40:25 2020
From: report at bugs.python.org (Manuel Barkhau)
Date: Fri, 24 Jan 2020 15:40:25 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579880425.31.0.99426903257.issue39390@roundup.psfhosted.org>


Change by Manuel Barkhau <mbarkhau at gmail.com>:


----------
pull_requests: +17554
pull_request: https://github.com/python/cpython/pull/18168

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Fri Jan 24 10:44:20 2020
From: report at bugs.python.org (Manuel Barkhau)
Date: Fri, 24 Jan 2020 15:44:20 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579880660.86.0.171088214088.issue39390@roundup.psfhosted.org>


Manuel Barkhau <mbarkhau at gmail.com> added the comment:

> For completeness, a similar problem is present also on python < 3.8

Fair point. I'll have a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Fri Jan 24 10:50:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jan 2020 15:50:47 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579881047.04.0.0311289268713.issue39390@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> For completeness, a similar problem is present also on python < 3.8 if passing a pathlib.Path type as *src*

I do not think this is a problem. If you pass a string, you will get a string, so existing code will continue to work as before. The only problem if you pass a string, but get an unexpected type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Fri Jan 24 10:58:01 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 24 Jan 2020 15:58:01 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579881481.24.0.84104855575.issue39390@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I don't think we need to change anything on < 3.8, but 3.8 and 3.9 will always convert *src* to str via os.fspath(), which IMO is more consistent (e.g. os.path.* functions and others do the same).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Fri Jan 24 11:02:12 2020
From: report at bugs.python.org (Manuel Barkhau)
Date: Fri, 24 Jan 2020 16:02:12 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1579881732.96.0.356008460354.issue39390@roundup.psfhosted.org>


Manuel Barkhau <mbarkhau at gmail.com> added the comment:

> If you pass a string, you will get a string, so existing code will continue to work as before.

Somebody might have code that is running against a flat directory and have written their ignore function expecting to get a pathlib.Path, because that's the only case they encountered. This change would break their code and so would an upgrade to 3.9 with the patch that was just merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Fri Jan 24 11:25:07 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 24 Jan 2020 16:25:07 +0000
Subject: [issue8901] Windows registry path not ignored with -E option
In-Reply-To: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za>
Message-ID: <1579883107.49.0.388182564007.issue8901@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +17555
pull_request: https://github.com/python/cpython/pull/18169

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8901>
_______________________________________

From report at bugs.python.org  Fri Jan 24 11:33:59 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 24 Jan 2020 16:33:59 +0000
Subject: [issue39442] from __future__ import annotations makes
 dataclasses.Field.type a string, not type
In-Reply-To: <1579866520.75.0.652812484582.issue39442@roundup.psfhosted.org>
Message-ID: <1579883639.22.0.142747328966.issue39442@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Well the type comes from the annotation, so this makes sense to me. If dataclasses were to call get_type_hints() for every field, it would defeat the purpose of PEP 563 (at least for dataclasses).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39442>
_______________________________________

From report at bugs.python.org  Fri Jan 24 11:50:23 2020
From: report at bugs.python.org (Maciej Gol)
Date: Fri, 24 Jan 2020 16:50:23 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579874904.2.0.992346888571.issue39430@roundup.psfhosted.org>
Message-ID: <CA+vMsyoFR=F3nhDAtKcvisFOG6713veAU=YF4n2c+8UTXSps4A@mail.gmail.com>


Maciej Gol <maciej.gol at curo.ch> added the comment:

This is a HUGE eye opener! Didn't know of that 'import' vs 'from x import
y' difference. Thanks a lot! Is it documented somewhere ?

pt., 24 sty 2020, 15:08 u?ytkownik Serhiy Storchaka <report at bugs.python.org>
napisa?:

>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> It is intended to support circular imports. Let foo.py contains "import
> bar" and bar.py contains "import foo". When you execute "import foo", the
> import machinery first creates an empty module foo, adds it to sys.modules,
> reads foo.py and executes it in the namespace of module foo. When the
> interpreter encounters "import bar" in foo.py, the import machinery creates
> an empty module bar, adds it to sys.modules, reads bar.py and executes it
> in the namespace of module bar. When the interpreter encounters "import
> foo" in bar.py, the import machinery takes the module foo from sys.modules.
> So you break an infinite cycle and can import modules with cyclic
> dependencies.
>
> You can argue that cyclic import does not look as a good practice, but
> actually it is pretty common case when you import a submodule in a package.
> If foo/__init__.py contains "from .bar import Bar", the foo module must be
> imported before you import foo.bar, but is not completely initialized at
> that time yet.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39430>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 12:01:37 2020
From: report at bugs.python.org (Steven DeRose)
Date: Fri, 24 Jan 2020 17:01:37 +0000
Subject: [issue39444] Incorrect description of sorting for PrettyPrinter
Message-ID: <1579885297.01.0.729190737587.issue39444@roundup.psfhosted.org>


New submission from Steven DeRose <sderose at acm.org>:

The doc for pprint.PrettyPrinter at https://docs.python.org/3/library/pprint.html says:

    If sort_dicts is true (the default), dictionaries will be formatted with their keys sorted, otherwise they will display in insertion order

I believe the insertion order is not even known by normal dicts (only by OrderedDict), so I think the last phrase must be wrong. If it's somehow correct, it deserves explaining....

----------
assignee: docs at python
components: Documentation
messages: 360630
nosy: TextGeek, docs at python
priority: normal
severity: normal
status: open
title: Incorrect description of sorting for PrettyPrinter
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39444>
_______________________________________

From report at bugs.python.org  Fri Jan 24 12:05:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 24 Jan 2020 17:05:27 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1579885527.9.0.117298121678.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 656c45ec9a9dc2e94cec199ebde553a6979e0e05 by Victor Stinner in branch 'master':
bpo-38631: Avoid Py_FatalError() in GC collect() (GH-18164)
https://github.com/python/cpython/commit/656c45ec9a9dc2e94cec199ebde553a6979e0e05


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Fri Jan 24 12:18:45 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Jan 2020 17:18:45 +0000
Subject: [issue39444] Incorrect description of sorting for PrettyPrinter
In-Reply-To: <1579885297.01.0.729190737587.issue39444@roundup.psfhosted.org>
Message-ID: <1579886325.8.0.489741545335.issue39444@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

dicts preserve their insertion order from Python 3.6 and is reflected in the documentation unless I am missing something here.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39444>
_______________________________________

From report at bugs.python.org  Fri Jan 24 12:23:17 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 24 Jan 2020 17:23:17 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
In-Reply-To: <1579776260.84.0.333075912412.issue39380@roundup.psfhosted.org>
Message-ID: <1579886597.23.0.560513877455.issue39380@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I agree with inada.naoki

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Fri Jan 24 12:51:45 2020
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 24 Jan 2020 17:51:45 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579888305.18.0.210828962986.issue39430@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Thanks, Serhiy!  I had no idea of those changes to import.

This does raise the question, though, of whether accessing an empty module's attributes should either:
- wait for the module to finish initializing; or
- raise an exception immediately with better information
?

It seems like this is a trap waiting for anybody using threaded code and on-demand imports.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 12:50:14 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 17:50:14 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579888214.55.0.667202338698.issue39430@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

It's covered in the language reference where import semantics are explained. It isn't explicitly called out in higher-level docs that I'm aware of because it only really comes up in edge cases like importing in a thread which we actively discourage unless there's a compelling reason not to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 12:56:11 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Jan 2020 17:56:11 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579888571.25.0.341270824271.issue39430@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17556
pull_request: https://github.com/python/cpython/pull/18171

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 12:56:12 2020
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 24 Jan 2020 17:56:12 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579888572.02.0.650244224933.issue39430@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 9017e0bd5e124ae6d2ed94b9e9cacb2e86270980 by Ethan Furman (Serhiy Storchaka) in branch 'master':
bpo-39430: Fix race condition in lazy imports in tarfile. (GH-18161)
https://github.com/python/cpython/commit/9017e0bd5e124ae6d2ed94b9e9cacb2e86270980


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 12:56:19 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Jan 2020 17:56:19 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579888579.59.0.871556586643.issue39430@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17557
pull_request: https://github.com/python/cpython/pull/18172

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 13:06:10 2020
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 24 Jan 2020 18:06:10 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579889170.2.0.104923361304.issue39430@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Brett:
------
> It's covered in the language reference where import semantics are
> explained. It isn't explicitly called out in higher-level docs that
> I'm aware of because it only really comes up in edge cases like
> importing in a thread which we actively discourage unless there's a
> compelling reason not to.

When was this change made?  Assuming it is, in fact, a change.  It seems like most of the stdlib could be called in a thread, so the practice of lazily importing a module wholesale might need to be audited and proactively fixed.  Maybe that could be a newcomer's easy(ish) project?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 13:21:59 2020
From: report at bugs.python.org (=?utf-8?q?Rafael_Laboissi=C3=A8re?=)
Date: Fri, 24 Jan 2020 18:21:59 +0000
Subject: [issue39445] h5py not playing nicely with subprocess and mpirun
Message-ID: <1579890119.79.0.971867657807.issue39445@roundup.psfhosted.org>


New submission from Rafael Laboissi?re <rafael at laboissiere.net>:

* Preamble:

The problem reported hereafter possibly comes from the h5py module, which is not part of Python per se. This problem has been already reported to the h5py developers: https://github.com/h5py/h5py/issues/1467

and also against the Debian package python3-h5py: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946986

I apologize if this issue report is considered abusive.  Please, feel free to close it, if it is the case.

* The problem:

The combination of "import h5py", "subprocess.Popen", and "mpirun" is yielding a weird result. Consider these two scripts:

#############################################################
### File name: bugtest-without-h5py.py
import subprocess
simulationProc = subprocess.Popen("mpirun",
                                  shell=True,
                                  stdout=subprocess.PIPE,
                                  stderr=subprocess.PIPE)
(stdout, stderr) = simulationProc.communicate()
returnCode = simulationProc.wait()
print("stdout = ", stdout)
print("stderr = ", stderr)
print("return code = ", returnCode)
#############################################################

#############################################################
### File name: bugtest-with-h5py.py
import subprocess
import h5py
simulationProc = subprocess.Popen("mpirun",
                                  shell=True,
                                  stdout=subprocess.PIPE,
                                  stderr=subprocess.PIPE)
(stdout, stderr) = simulationProc.communicate()
returnCode = simulationProc.wait()
print("stdout = ", stdout)
print("stderr = ", stderr)
print("return code = ", returnCode)
#############################################################

The only difference between them is the line containing "import h5py" in the second.

Here is the result when running the first script:

   $ python3 bugtest-without-h5py.py
   stdout =  b''
   stderr =  b'--------------------------------------------------------------------------\nmpirun could not find anything to do.\n\nIt is possible that you forgot to specify how many processes to run\nvia the "-np" argument.\n--------------------------------------------------------------------------\n'
   return code =  1

and here is the result for the second script:

   $ python3 bugtest-with-h5py.py
   stdout =  b''
   stderr =  b''
   return code =  1

It seems that, when h5py is imported, the mpirun command is not even launched by subprocess.Popen, even though there is noting in this call that is related to h5py.

When "mpirun" is replaced by other commands (e.g. "date"), then the output is identical for both scripts, as it should be.

As I wrote in the preamble, this is possibly a problem with h5py.  I am reporting it here because the developers of the subprocess module may have an idea about the origin of the problem or give me a hint on how to debug the it.

The tests were done on a Debian bullseye system with the following versions:

h5py 2.10.0 (compiled with MPI support)
Python 3.7.6

----------
components: Library (Lib)
messages: 360638
nosy: Rafael Laboissi?re
priority: normal
severity: normal
status: open
title: h5py not playing nicely with subprocess and mpirun
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39445>
_______________________________________

From report at bugs.python.org  Fri Jan 24 13:53:02 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 24 Jan 2020 18:53:02 +0000
Subject: [issue39405] Using relative path as a --prefix during configure.
In-Reply-To: <1579593132.28.0.601505757933.issue39405@roundup.psfhosted.org>
Message-ID: <1579891982.92.0.228822871719.issue39405@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Hello!  I suggest you bring your question to the forum, which is a better place to have discussions than the issue tracker :)

https://discuss.python.org/c/users/7

----------
nosy: +eric.araujo
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39405>
_______________________________________

From report at bugs.python.org  Fri Jan 24 14:03:40 2020
From: report at bugs.python.org (David Hagen)
Date: Fri, 24 Jan 2020 19:03:40 +0000
Subject: [issue39442] from __future__ import annotations makes
 dataclasses.Field.type a string, not type
In-Reply-To: <1579866520.75.0.652812484582.issue39442@roundup.psfhosted.org>
Message-ID: <1579892620.05.0.305281751286.issue39442@roundup.psfhosted.org>


David Hagen <david at drhagen.com> added the comment:

Should `dataclass.Field.type` become a property that evaluates the annotation at runtime much in the same way that `get_type_hints` works?

----------
nosy: +drhagen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39442>
_______________________________________

From report at bugs.python.org  Fri Jan 24 14:17:37 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 24 Jan 2020 19:17:37 +0000
Subject: [issue39414] Multiprocessing resolving object as None
In-Reply-To: <1579626467.92.0.021176656048.issue39414@roundup.psfhosted.org>
Message-ID: <1579893457.92.0.82069408001.issue39414@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39414>
_______________________________________

From report at bugs.python.org  Fri Jan 24 14:27:13 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 24 Jan 2020 19:27:13 +0000
Subject: [issue39442] from __future__ import annotations makes
 dataclasses.Field.type a string, not type
In-Reply-To: <1579866520.75.0.652812484582.issue39442@roundup.psfhosted.org>
Message-ID: <1579894033.3.0.509420889762.issue39442@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

> Should `dataclass.Field.type` become a property that evaluates the annotation at runtime much in the same way that `get_type_hints` works?

I think not. But maybe a function that evaluates all of the field types. Or maybe an @dataclass parameter to cause it to happen at definition time.

At this point, this seems more like fodder for python-ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39442>
_______________________________________

From report at bugs.python.org  Fri Jan 24 14:27:50 2020
From: report at bugs.python.org (Michael Shields)
Date: Fri, 24 Jan 2020 19:27:50 +0000
Subject: [issue39446] Documentation should reflect that all dicts are now
 ordered
Message-ID: <1579894070.69.0.0178320617027.issue39446@roundup.psfhosted.org>


New submission from Michael Shields <michael.shields at freenome.com>:

As of Python 3.7, dicts always preserve insertion order. This is mentioned briefly in the release notes, but it would also be helpful to mention it in the language reference, and in the discussion of collections.OrderedDict.

----------
assignee: docs at python
components: Documentation
messages: 360642
nosy: Michael Shields, docs at python
priority: normal
severity: normal
status: open
title: Documentation should reflect that all dicts are now ordered
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39446>
_______________________________________

From report at bugs.python.org  Fri Jan 24 14:31:40 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 24 Jan 2020 19:31:40 +0000
Subject: [issue39435] pickle: inconsistent arguments pickle.py vs _pickle.c vs
 docs
In-Reply-To: <1579799539.42.0.511265830635.issue39435@roundup.psfhosted.org>
Message-ID: <1579894300.5.0.979487829503.issue39435@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

As mentioned on the attached PR, the first argument is positional, so it doesn't matter that the name in the docs is not the same as the name in the code.

The name "bytes_object" makes it clear which type of object is accepted, which makes it a better fit IMHO than "data".  Therefore, I'm going to close this issue.

----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39435>
_______________________________________

From report at bugs.python.org  Fri Jan 24 14:36:07 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 24 Jan 2020 19:36:07 +0000
Subject: [issue39443] Inhomogeneous behaviour for descriptors in between the
 class-instance and metaclass-class pairs
In-Reply-To: <1579879054.45.0.122838509696.issue39443@roundup.psfhosted.org>
Message-ID: <1579894567.45.0.490440058355.issue39443@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

First of all, thanks for asking about this.  Everything is working as expected.  Let's look at why.

First, be sure the behavior of descriptors is clear: the descriptor protocol is only triggered by "dotted access" on an object ("obj.attr").  So you should expect it only where you see that syntax used.

Let's look at your examples now.

> FirstClass().descriptor = None

In this case there are 2 dotted accesses.  The first one happens in __init__() when the object is created.  The second is the rest of the above line.

> class SecondClass(metaclass=SecondClassMeta):
>    descriptor = None
>
> SecondClass.descriptor = None

In this case there is only one dotted access, in that last line.  The object in this case is SecondClass and its class is SecondClassMeta.  Unlike with FirstClass, the *class* in the second example (SecondClassMeta) does not have a __init__() with the dotted access.  Instead there is only the one dotted access afterward.  If SecondClassMeta had the same __init__() that FirstClass had then you would have seen a second trigger of the descriptor.

It seems you expected assignments (name binding) in the class definition body to be treated the same as dotted access.  They are not.  This is because when a class definition body is evaluated, the class object does not exist yet.  The steps for class creation go like this:

1. figure out the metaclass (by default "type")
2. calls its __prepare__() method to get a namespace
3. execute the class body (like a function) with that namespace as the locals
4. create the class object, passing in that namespace

Python has worked this way since version 2.2 (PEP 252).  See: https://docs.python.org/3/reference/datamodel.html#creating-the-class-object

If you want to get clever you could return a namespace object from your metaclass __prepare__ that triggers the descriptor protocol as you expected.  However, I would not recommend that.  Getting clever with metaclasses is best avoided.  The default behavior is much simpler.  That won't be changing.

> It looks to me like an undesirable asymmetry between the descriptors behaviour when in classes vs when in metaclasses. Is that intended? If it is, I think it should be highlighted in the descriptors documentation.

Regardless, metaclasses are used infrequently and combining them with descriptors (especially relative to class definitions) is even less common.  So pointing out the caveats of this case may not be worth the time of all future readers of those docs.

That said, clearly it would have helped you in this case. :)  So here are some *possible* places to clarify (very briefly):

* descriptors howto
   + about mixing descriptors with metaclasses
   + a list enumerating places where descriptors are *not* invoked
* language reference (metaclasses section)
   + a warning saying something like "Avoid metaclasses if you can help it and only use them if you have a clear understanding of Python's object model (and dotted access)"
* language reference (descriptors/dotted access section)
   + a list enumerating places where descriptors are *not* invoked

Which of those do you think would have helped you the most?

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39443>
_______________________________________

From report at bugs.python.org  Fri Jan 24 14:36:31 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Jan 2020 19:36:31 +0000
Subject: [issue39446] Documentation should reflect that all dicts are now
 ordered
In-Reply-To: <1579894070.69.0.0178320617027.issue39446@roundup.psfhosted.org>
Message-ID: <1579894591.51.0.0136393527161.issue39446@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +inada.naoki, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39446>
_______________________________________

From report at bugs.python.org  Fri Jan 24 14:37:28 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 24 Jan 2020 19:37:28 +0000
Subject: [issue39443] Inhomogeneous behaviour for descriptors in between the
 class-instance and metaclass-class pairs
In-Reply-To: <1579879054.45.0.122838509696.issue39443@roundup.psfhosted.org>
Message-ID: <1579894648.57.0.0533607281152.issue39443@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@Raymond, What do you think about adding a helpful note or two in the docs?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39443>
_______________________________________

From report at bugs.python.org  Fri Jan 24 14:38:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 24 Jan 2020 19:38:49 +0000
Subject: [issue39446] Documentation should reflect that all dicts are now
 ordered
In-Reply-To: <1579894070.69.0.0178320617027.issue39446@roundup.psfhosted.org>
Message-ID: <1579894729.25.0.13028053473.issue39446@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also https://bugs.python.org/issue33609 .

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39446>
_______________________________________

From report at bugs.python.org  Fri Jan 24 14:44:34 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 19:44:34 +0000
Subject: [issue38972] [venv] Link to instructions to change PowerShell
 execution policy for venv activation
In-Reply-To: <1575483846.28.0.24893284684.issue38972@roundup.psfhosted.org>
Message-ID: <1579895074.22.0.126442602356.issue38972@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

https:/go.microsoft.com/fwlink/?LinkID=135170 is the link to the MS docs.

The command is:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38972>
_______________________________________

From report at bugs.python.org  Fri Jan 24 15:00:05 2020
From: report at bugs.python.org (Dino Viehland)
Date: Fri, 24 Jan 2020 20:00:05 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579896005.03.0.007458593634.issue38076@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

One more data point: Backporting this change to Python 3.6 (I just happened to have it applied there already, so I haven't tried it on 3.7 or 3.8) has no crash and no hangs in multiprocessing on Linux.  So something definitely changed in multiproessing which is causing the hang on shutdown, and forces us into this code path where we crash as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Fri Jan 24 15:10:50 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Jan 2020 20:10:50 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579896650.8.0.2829978343.issue39430@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ea4a61fec842c94107eef46e5030b89a086f94bb by Miss Islington (bot) in branch '3.8':
bpo-39430: Fix race condition in lazy imports in tarfile. (GH-18161)
https://github.com/python/cpython/commit/ea4a61fec842c94107eef46e5030b89a086f94bb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 15:10:56 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 24 Jan 2020 20:10:56 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579896656.56.0.550646073828.issue39430@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1a274359283d3d1f4f60dd527843f72e0368caf3 by Miss Islington (bot) in branch '3.7':
bpo-39430: Fix race condition in lazy imports in tarfile. (GH-18161)
https://github.com/python/cpython/commit/1a274359283d3d1f4f60dd527843f72e0368caf3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 15:12:01 2020
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 24 Jan 2020 20:12:01 +0000
Subject: [issue22724] byte-compile fails for cross-builds
In-Reply-To: <1414194759.57.0.515625475535.issue22724@psf.upfronthosting.co.za>
Message-ID: <1579896721.71.0.87886262292.issue22724@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

PYTHON_FOR_BUILD does not use PYTHONPATH in the implementation of (closed) PR 17420 and should fix the current issue as a side effect.

FWIW, PR 17420 fixes cross-compilation of third-party extension modules by replacing the complex PYTHON_FOR_BUILD command line set in configure.ac by the more simple command:

    "PYTHON_FOR_BUILD='PYTHON_PROJECT_BASE=$(abs_builddir) '$interp"

In this PR finding the path name of the target sysconfigdata module when needed is done by the sysconfig module and by distutils using the Misc/python-config.sh.in script instead of using PYTHONPATH.

Since PYTHONPATH is not used in PR 17420, the current issue should also be fixed by the PR. See also Benedikt OP that provided a hint for the fix.

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22724>
_______________________________________

From report at bugs.python.org  Fri Jan 24 15:24:36 2020
From: report at bugs.python.org (Daniel Kahn Gillmor)
Date: Fri, 24 Jan 2020 20:24:36 +0000
Subject: [issue39447] imaplib documentation claims that commands return a
 string, but they return bytes
Message-ID: <1579897476.32.0.1859965096.issue39447@roundup.psfhosted.org>


New submission from Daniel Kahn Gillmor <dkg at fifthhorseman.net>:

The imaplib documentation says:


> Each command returns a tuple: (type, [data, ...]) where type is usually 
> 'OK' or 'NO', and data is either the text from the command response, or 
> mandated results from the command. Each data is either a string, or a
> tuple. If a tuple, then the first part is the header of the response, 
> and the second part contains the data (ie: ?literal? value).

However, "Each data is either a string, or a tuple" does not appear to be correct.   If the element of data is not a tuple, it appears to be a bytes object, not a string (because it is dealing with network streams of bytes internally)

This is probably old documentation left over from python 2, when strings and bytes were the same.

----------
components: email
messages: 360652
nosy: barry, dkg, r.david.murray
priority: normal
severity: normal
status: open
title: imaplib documentation claims that commands return a string, but they return bytes
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39447>
_______________________________________

From report at bugs.python.org  Fri Jan 24 15:25:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 24 Jan 2020 20:25:25 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579897525.2.0.445014042423.issue39430@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I suppose it fixed the bug. But I cannot confirm because I cannot reproduce the original bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Fri Jan 24 15:35:09 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 24 Jan 2020 20:35:09 +0000
Subject: [issue39395] The os module should unset() environment variable at exit
In-Reply-To: <1579521534.52.0.738486244649.issue39395@roundup.psfhosted.org>
Message-ID: <1579898109.55.0.747782970122.issue39395@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FTR, #39376 is related (avoid the process-global env vars in the first place).

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39395>
_______________________________________

From report at bugs.python.org  Fri Jan 24 15:52:47 2020
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 24 Jan 2020 20:52:47 +0000
Subject: [issue39448] Add regen-frozen makefile target
Message-ID: <1579899167.9.0.743060780992.issue39448@roundup.psfhosted.org>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

Updating the frozen module "__hello__" code inside Python/frozen.c is currently a manual process.  That's a bit tedious since it adds some extra work in the case that bytecode changes are made.  I've created a small script and a makefile target to automates the process.

----------
messages: 360655
nosy: nascheme
priority: normal
severity: normal
stage: patch review
status: open
title: Add regen-frozen makefile target
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39448>
_______________________________________

From report at bugs.python.org  Fri Jan 24 15:57:56 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 24 Jan 2020 20:57:56 +0000
Subject: [issue38076] Make struct module PEP-384 compatible
In-Reply-To: <1568046908.42.0.641730550956.issue38076@roundup.psfhosted.org>
Message-ID: <1579899476.91.0.671158878485.issue38076@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> there's still probably some underlying issue in multiprocessing.

Whoa, I've never heard that before!  <wink>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38076>
_______________________________________

From report at bugs.python.org  Fri Jan 24 16:35:50 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jan 2020 21:35:50 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
In-Reply-To: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>
Message-ID: <1579901750.54.0.208023714242.issue39374@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree that we should keep 'function', as it is often used at least somewhat generically (as in Library Manual 'Built-in Functions' chapter). I marked this as an easy first PR.

----------
keywords: +easy, newcomer friendly
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39374>
_______________________________________

From report at bugs.python.org  Fri Jan 24 16:38:50 2020
From: report at bugs.python.org (Daniel Kahn Gillmor)
Date: Fri, 24 Jan 2020 21:38:50 +0000
Subject: [issue39447] imaplib documentation claims that commands return a
 string, but they return bytes
In-Reply-To: <1579897476.32.0.1859965096.issue39447@roundup.psfhosted.org>
Message-ID: <1579901930.18.0.390151710789.issue39447@roundup.psfhosted.org>


Daniel Kahn Gillmor <dkg at fifthhorseman.net> added the comment:

I should note that the "header of the response" appears to also be a bytes object, not a string object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39447>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:13:50 2020
From: report at bugs.python.org (Arthur Fibich)
Date: Fri, 24 Jan 2020 23:13:50 +0000
Subject: [issue39449] New Assignment operator
Message-ID: <1579907630.13.0.450663882045.issue39449@roundup.psfhosted.org>


New submission from Arthur Fibich <arthurfibich at gmail.com>:

It's just a personal thing, but I kind of miss the following possibility in Python (and likewise every other language I know):
Like 
a += 1 
is the same as
a = a + 1

I'd love to see
a .= b()
as an opportunity to express
a = a.b()

Possible usages are for example linked lists or other structures, where a class's attributes or methods are/return an object of the same type.

----------
components: Interpreter Core
messages: 360659
nosy: Arthur Fibich
priority: normal
severity: normal
status: open
title: New Assignment operator
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39449>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:22:10 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jan 2020 23:22:10 +0000
Subject: [issue39392] Python Turtle is not filling alternate overlapping areas
 of a shape with same color
In-Reply-To: <1579497263.75.0.682788787706.issue39392@roundup.psfhosted.org>
Message-ID: <1579908130.83.0.727094627609.issue39392@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Your SO question is essentially a duplicate.  As I answered there, the graphics systems of Unix and Windows, used by tk and hence tkinter, handle filling of self-intersecting polygons differently.  On Windows, if one draws a line from the outside to a particular region without going through an intersection, each line crossing toggles 'fill', starting with 'off' in the outside.

The rule seems to be reversed for overlapping items, such as circles.  On Windows, all three circles are yellow, whereas on macOS, the 60 circle is white, even if drawn last!

So, no bug.  The best we can do is document 'filling' for turtle.  Our tkinter doc does not include tk widgets, in particular Canvas, and we cannot edit external sources.

What happens with multiple fill colors?  Blended, or last wins?

# 1 fill block
from turtle import *
color('black', 'yellow')    
begin_fill()
circle(40)
color('black', 'red')    
circle(60)
color('black', 'blue')    
circle(80)
end_fill()

On Windows, 3 circles drawn, then all filled with blue.  The same is true if the circle order is reversed.

# multiple fill blocks
from turtle import *
color('black', 'yellow')    
begin_fill()
circle(40)
end_fill()
color('black', 'red')    
begin_fill()
circle(60)
end_fill()
color('black', 'blue')    
begin_fill()
circle(80)
end_fill()

On Windows, each circle fills with its color after it is drawn.  Same final result.  It is different if drawing order is reversed.  The rule seems to be: lines are drawn with the current line color; fill is done at the end of each fill block with the current (last) fill color.

----------
assignee:  -> docs at python
components: +Documentation -Tkinter
nosy: +docs at python, terry.reedy
stage:  -> needs patch
type: behavior -> 
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39392>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:26:08 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:26:08 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1579908368.14.0.0367416094725.issue10572@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

In case anyone cares, this is still a thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:26:13 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:26:13 +0000
Subject: [issue10572] Move test sub-packages to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1579908373.65.0.553064823772.issue10572@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:26:31 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:26:31 +0000
Subject: [issue8400] zipimporter find_module fullname mis-documented
In-Reply-To: <1271258442.34.0.660774695694.issue8400@psf.upfronthosting.co.za>
Message-ID: <1579908391.14.0.952243630153.issue8400@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8400>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:27:41 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:27:41 +0000
Subject: [issue8627] Unchecked PyErr_WarnPy3k return value in
 Objects/typeobject.c
In-Reply-To: <1273069856.93.0.435136167669.issue8627@psf.upfronthosting.co.za>
Message-ID: <1579908461.49.0.821115949826.issue8627@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8627>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:28:07 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:28:07 +0000
Subject: [issue8901] Windows registry path not ignored with -E option
In-Reply-To: <1275705565.03.0.753930892849.issue8901@psf.upfronthosting.co.za>
Message-ID: <1579908487.43.0.980402884052.issue8901@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8901>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:28:13 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:28:13 +0000
Subject: [issue8912] `make patchcheck` should check the whitespace of .c/.h
 files
In-Reply-To: <1275794679.2.0.211731721822.issue8912@psf.upfronthosting.co.za>
Message-ID: <1579908493.42.0.482726489358.issue8912@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8912>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:28:31 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:28:31 +0000
Subject: [issue8987] Distutils doesn't quote Windows command lines properly
In-Reply-To: <1276406573.22.0.576013989845.issue8987@psf.upfronthosting.co.za>
Message-ID: <1579908511.1.0.79967412048.issue8987@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8987>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:30:25 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:30:25 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1579908625.43.0.466639380361.issue13886@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13886>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:30:40 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:30:40 +0000
Subject: [issue13328] pdb shows code from wrong module
In-Reply-To: <1320278597.67.0.4589054929.issue13328@psf.upfronthosting.co.za>
Message-ID: <1579908640.05.0.335182045714.issue13328@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13328>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:31:08 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:31:08 +0000
Subject: [issue13306] Add diagnostic tools to importlib?
In-Reply-To: <1320098820.25.0.925823454462.issue13306@psf.upfronthosting.co.za>
Message-ID: <1579908668.4.0.577463333966.issue13306@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13306>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:31:39 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:31:39 +0000
Subject: [issue13306] Add diagnostic tools to importlib?
In-Reply-To: <1320098820.25.0.925823454462.issue13306@psf.upfronthosting.co.za>
Message-ID: <1579908699.66.0.458019931054.issue13306@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I'm going to close this as I think this belongs more on PyPI than in the stdlib (feel free to re-open if you disagree, Nick).

----------
nosy: +brett.cannon
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13306>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:32:27 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:32:27 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1579908747.42.0.709466126948.issue12915@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:32:31 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jan 2020 23:32:31 +0000
Subject: [issue39441] mimetypes.guess_extension unable to get non-lowercase
 mimetype
In-Reply-To: <1579859419.07.0.145257790189.issue39441@roundup.psfhosted.org>
Message-ID: <1579908751.24.0.425774543564.issue39441@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39441>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:32:56 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:32:56 +0000
Subject: [issue11978] Report correct coverage.py data for tests that invoke
 subprocesses
In-Reply-To: <1304343970.06.0.71963253791.issue11978@psf.upfronthosting.co.za>
Message-ID: <1579908776.56.0.234222796837.issue11978@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11978>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:33:32 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:33:32 +0000
Subject: [issue11549] Build-out an AST optimizer,
 moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1579908812.06.0.768879974822.issue11549@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:33:58 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 24 Jan 2020 23:33:58 +0000
Subject: [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1579908838.66.0.758110549444.issue11553@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11553>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:34:15 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 24 Jan 2020 23:34:15 +0000
Subject: [issue39444] Incorrect description of sorting for PrettyPrinter
In-Reply-To: <1579885297.01.0.729190737587.issue39444@roundup.psfhosted.org>
Message-ID: <1579908855.84.0.168909256856.issue39444@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

How about 'in their default insertion order'?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39444>
_______________________________________

From report at bugs.python.org  Fri Jan 24 18:52:16 2020
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 24 Jan 2020 23:52:16 +0000
Subject: [issue39448] Add regen-frozen makefile target
In-Reply-To: <1579899167.9.0.743060780992.issue39448@roundup.psfhosted.org>
Message-ID: <1579909936.17.0.120037354308.issue39448@roundup.psfhosted.org>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
keywords: +patch
pull_requests: +17558
pull_request: https://github.com/python/cpython/pull/18174

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39448>
_______________________________________

From report at bugs.python.org  Fri Jan 24 19:14:07 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 25 Jan 2020 00:14:07 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1579911247.4.0.84930622198.issue12915@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

With the lack of support, I suggest closing this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Fri Jan 24 19:23:39 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 25 Jan 2020 00:23:39 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1579911819.54.0.258685162008.issue10740@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

With Berker Peksag's patch merged in 2016, in the default non auto-commit mode, sqlite3 implicitly issues a BEGIN statement before any non SELECT statement not already in a transaction, EXCEPT DDL statements, for backwards compatibility reasons:

+    /* For backwards compatibility reasons, do not start a transaction if a
+       DDL statement is encountered.  If anybody wants transactional DDL,
+       they can issue a BEGIN statement manually. */
+    if (self->connection->begin_statement && !sqlite3_stmt_readonly(self->statement->st) && !self->statement->is_ddl) {
+        if (sqlite3_get_autocommit(self->connection->db)) {
+            result = _pysqlite_connection_begin(self->connection);
+            if (!result) {
+                goto error;
+            }
+            Py_DECREF(result);
         }
     }

Is there any plan to cover DDL statements as well in a future Python version and deprecate the old behaviour? That would avoid having to insert BEGIN statements manually for getting transactional DDL statements, like in psycopg2 for PostgreSQL databases.

----------
nosy: +maggyero

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Fri Jan 24 20:03:33 2020
From: report at bugs.python.org (Steve C)
Date: Sat, 25 Jan 2020 01:03:33 +0000
Subject: [issue39450] unittest TestCase shortDescription does not strip
 whitespace
Message-ID: <1579914213.48.0.14030240002.issue39450@roundup.psfhosted.org>


New submission from Steve C <scirelli at gmail.com>:

When running unit tests with the --verbose flag test descriptions are run using the first line of the test case's docstring. If the first character of the docstring is a newline, no description is printed.
Examples:
Current code expects docstrings to look like
'''It should return blah blah
This is a test...
'''
Where the description starts on the first line.

Some Python developers start the string on the next line. Example:
'''
It should return blah blah
This is a test...
'''

Lib.unittest.case.TestCase:shortDescription should first strip the docstrip of beginning and trailing whitespace.

----------
components: Library (Lib)
messages: 360666
nosy: Steve C2
priority: normal
severity: normal
status: open
title: unittest TestCase shortDescription does not strip whitespace
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39450>
_______________________________________

From report at bugs.python.org  Fri Jan 24 20:33:39 2020
From: report at bugs.python.org (Steve C)
Date: Sat, 25 Jan 2020 01:33:39 +0000
Subject: [issue39450] unittest TestCase shortDescription does not strip
 whitespace
In-Reply-To: <1579914213.48.0.14030240002.issue39450@roundup.psfhosted.org>
Message-ID: <1579916019.17.0.910804468121.issue39450@roundup.psfhosted.org>


Change by Steve C <scirelli at gmail.com>:


----------
keywords: +patch
pull_requests: +17559
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18175

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39450>
_______________________________________

From report at bugs.python.org  Fri Jan 24 21:19:23 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jan 2020 02:19:23 +0000
Subject: [issue39388] IDLE: Changes to keybindings aren't reverted on cancel
In-Reply-To: <1579454814.83.0.214082959531.issue39388@roundup.psfhosted.org>
Message-ID: <1579918763.68.0.226918200468.issue39388@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for the reminder.  There must be other changes not being cancelled, but I will finish this fix instead of measuring the bug ;-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39388>
_______________________________________

From report at bugs.python.org  Fri Jan 24 21:47:54 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jan 2020 02:47:54 +0000
Subject: [issue39449] New Assignment operator
In-Reply-To: <1579907630.13.0.450663882045.issue39449@roundup.psfhosted.org>
Message-ID: <1579920474.52.0.503307672215.issue39449@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This is a syntax change and it should be discussed in python-ideas mailing list first and would require a PEP. I would suggest closing it now and reopening it if the idea is accepted.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39449>
_______________________________________

From report at bugs.python.org  Sat Jan 25 00:09:55 2020
From: report at bugs.python.org (Martin Panter)
Date: Sat, 25 Jan 2020 05:09:55 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1579928995.49.0.610546003108.issue39353@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Of course I would prefer ?crc_hqx? to stay, because we use it at work. But I understand if you think it is not popular enough to justify maintaining it.

But I was more asking if the deprecation notice should point the way forward. This function is no longer recommended, so what should users do instead? Or at least explain why it is deprecated.

In my case, I may eventually write or resurrect a simple Python CRC implementation that shifts one bit at a time. But other people may desire a faster C implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Sat Jan 25 01:30:33 2020
From: report at bugs.python.org (Dan Gass)
Date: Sat, 25 Jan 2020 06:30:33 +0000
Subject: [issue39451] enum.Enum reference count leaks
Message-ID: <1579933833.85.0.945475764886.issue39451@roundup.psfhosted.org>


New submission from Dan Gass <dan.gass at gmail.com>:

Given
(1) instantiation of an enumeration class with an invalid value
(2) a try/except around the instantiation where the exception is ignored

Then:
An unneeded reference to the bad value is lost (as well as other values that I suspect are local variables within a participating method)

When run, the attached sample script shows before and after reference counts which demonstrate the potential resource leaks. The sample script includes the output from running the script on Python version 3.7.5 within the module docstring.

The root cause appears to be in the exception handling in the Enum.__new__ method (in the area where it calls the _missing_ hook). The attached sample script includes a simplified version of those methods that should help pinpoint the code in question and confirm the root cause.

Not being an exception nitty-gritty expert, I have suspicions that users should be warned about using this pattern of exception handling. I suspect this pattern would be worth avoiding in the Enum implementation.

I am willing to take a stab at submitting a patch for Enum. I hesitate slightly not knowing if there are specific reasons for the code existing in its current form. Alternatively, I plan on being at PyCon2020 for the sprints and could be available then to work on it.

----------
components: Library (Lib)
files: sample.py
messages: 360670
nosy: dan.gass at gmail.com
priority: normal
severity: normal
status: open
title: enum.Enum reference count leaks
type: resource usage
versions: Python 3.7
Added file: https://bugs.python.org/file48863/sample.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39451>
_______________________________________

From report at bugs.python.org  Sat Jan 25 01:57:59 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 25 Jan 2020 06:57:59 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
In-Reply-To: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>
Message-ID: <1579935479.42.0.574769911334.issue39374@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17560
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18177

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39374>
_______________________________________

From report at bugs.python.org  Sat Jan 25 02:01:25 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 25 Jan 2020 07:01:25 +0000
Subject: [issue39444] Incorrect description of sorting for PrettyPrinter
In-Reply-To: <1579885297.01.0.729190737587.issue39444@roundup.psfhosted.org>
Message-ID: <1579935685.38.0.607106481579.issue39444@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I don't think that any change is needed here. Adding "their default" to insertion order doesn't really help: if the reader knows dicts are now ordered, adding "default" is redundant; if the reader doesn't know, they'll still be confused. "What default insertion order? Dicts don't know their insertion order!" (Well actually they do.)

In a handful of more releases, most Python programmers won't even know, or will have forgotten, that there was ever a time that dicts didn't preserve insertion order, just as most of them don't know that there was ever a time that sorting wasn't stable or that dicts lacked an `update` method :-)

No offense to Steven here, but the problem wasn't with the docs (they are correct and accurate) but with his outdated knowledge of dicts. It's a perfectly understandable mistake to make, but it was a mistake.

I'm closing the task, but if anyone feels strongly enough to re-open it, I won't object.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39444>
_______________________________________

From report at bugs.python.org  Sat Jan 25 02:05:52 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jan 2020 07:05:52 +0000
Subject: [issue39451] enum.Enum reference count leaks
In-Reply-To: <1579933833.85.0.945475764886.issue39451@roundup.psfhosted.org>
Message-ID: <1579935952.39.0.855015781795.issue39451@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +barry, eli.bendersky, ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39451>
_______________________________________

From report at bugs.python.org  Sat Jan 25 02:12:57 2020
From: report at bugs.python.org (Juhana Jauhiainen)
Date: Sat, 25 Jan 2020 07:12:57 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
In-Reply-To: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>
Message-ID: <1579936377.42.0.460502204437.issue39374@roundup.psfhosted.org>


Juhana Jauhiainen <juhana.jauhiainen at gmail.com> added the comment:

I created a pull request for this issue. It adds the description "(or other callable)" to two places in sorting documentation.

"function (or other callable) to be called on each list element prior to making
comparisons."

and later

"The value of the *key* parameter should be a function (or other callable) that takes a single argument and returns a key to use for sorting purposes."

----------
nosy: +Juhana.Jauhiainen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39374>
_______________________________________

From report at bugs.python.org  Sat Jan 25 02:37:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jan 2020 07:37:12 +0000
Subject: [issue39444] Incorrect description of sorting for PrettyPrinter
In-Reply-To: <1579885297.01.0.729190737587.issue39444@roundup.psfhosted.org>
Message-ID: <1579937832.76.0.147820570382.issue39444@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Closing is fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39444>
_______________________________________

From report at bugs.python.org  Sat Jan 25 04:01:19 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jan 2020 09:01:19 +0000
Subject: [issue39388] IDLE: Changes to keybindings aren't reverted on cancel
In-Reply-To: <1579454814.83.0.214082959531.issue39388@roundup.psfhosted.org>
Message-ID: <1579942879.37.0.0427101512254.issue39388@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17562
pull_request: https://github.com/python/cpython/pull/18178

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39388>
_______________________________________

From report at bugs.python.org  Sat Jan 25 04:01:21 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jan 2020 09:01:21 +0000
Subject: [issue39388] IDLE: Changes to keybindings aren't reverted on cancel
In-Reply-To: <1579454814.83.0.214082959531.issue39388@roundup.psfhosted.org>
Message-ID: <1579942881.14.0.984251077739.issue39388@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset d0d9fa8c5e30aff71b6d5e8b2673396622f33270 by Terry Jan Reedy (Cheryl Sabella) in branch 'master':
bpo-39388: IDLE: Fix bug when cancelling out of configdialog (GH-18068)
https://github.com/python/cpython/commit/d0d9fa8c5e30aff71b6d5e8b2673396622f33270


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39388>
_______________________________________

From report at bugs.python.org  Sat Jan 25 04:01:22 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jan 2020 09:01:22 +0000
Subject: [issue39388] IDLE: Changes to keybindings aren't reverted on cancel
In-Reply-To: <1579454814.83.0.214082959531.issue39388@roundup.psfhosted.org>
Message-ID: <1579942882.85.0.640645393607.issue39388@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17563
pull_request: https://github.com/python/cpython/pull/18179

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39388>
_______________________________________

From report at bugs.python.org  Sat Jan 25 04:17:58 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jan 2020 09:17:58 +0000
Subject: [issue39388] IDLE: Changes to keybindings aren't reverted on cancel
In-Reply-To: <1579454814.83.0.214082959531.issue39388@roundup.psfhosted.org>
Message-ID: <1579943878.35.0.999322095082.issue39388@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a23449285430081ea317cc1f203c80c410bbd8b9 by Miss Islington (bot) in branch '3.8':
bpo-39388: IDLE: Fix bug when cancelling out of configdialog (GH-18068)
https://github.com/python/cpython/commit/a23449285430081ea317cc1f203c80c410bbd8b9


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39388>
_______________________________________

From report at bugs.python.org  Sat Jan 25 04:18:32 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jan 2020 09:18:32 +0000
Subject: [issue39388] IDLE: Changes to keybindings aren't reverted on cancel
In-Reply-To: <1579454814.83.0.214082959531.issue39388@roundup.psfhosted.org>
Message-ID: <1579943912.3.0.944050253082.issue39388@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fd9ce2b924263c1f5c5a2f3f3095fe6ae97c1432 by Miss Islington (bot) in branch '3.7':
bpo-39388: IDLE: Fix bug when cancelling out of configdialog (GH-18068)
https://github.com/python/cpython/commit/fd9ce2b924263c1f5c5a2f3f3095fe6ae97c1432


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39388>
_______________________________________

From report at bugs.python.org  Sat Jan 25 04:23:45 2020
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 25 Jan 2020 09:23:45 +0000
Subject: [issue39435] pickle: inconsistent arguments pickle.py vs _pickle.c vs
 docs
In-Reply-To: <1579799539.42.0.511265830635.issue39435@roundup.psfhosted.org>
Message-ID: <1579944225.88.0.71892626936.issue39435@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Reopening because it seems my reading of the doc was wrong (took a backslash for a regular slash :-o).

----------
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39435>
_______________________________________

From report at bugs.python.org  Sat Jan 25 05:17:50 2020
From: report at bugs.python.org (Chris Withers)
Date: Sat, 25 Jan 2020 10:17:50 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
In-Reply-To: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>
Message-ID: <1579947470.6.0.0639734139708.issue39082@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 62865f4532094017a9b780b704686ca9734bc329 by Chris Withers (Matthew Kokotovich) in branch 'master':
bpo-39082: Allow AsyncMock to correctly patch static/class methods (GH-18116)
https://github.com/python/cpython/commit/62865f4532094017a9b780b704686ca9734bc329


----------
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Sat Jan 25 05:18:45 2020
From: report at bugs.python.org (Chris Withers)
Date: Sat, 25 Jan 2020 10:18:45 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
In-Reply-To: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>
Message-ID: <1579947525.51.0.691293739049.issue39082@roundup.psfhosted.org>


Change by Chris Withers <chris at withers.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Sat Jan 25 05:53:57 2020
From: report at bugs.python.org (Chris Withers)
Date: Sat, 25 Jan 2020 10:53:57 +0000
Subject: [issue37955] mock.patch incorrect reference to Mock
In-Reply-To: <1566832308.08.0.460509709565.issue37955@roundup.psfhosted.org>
Message-ID: <1579949637.48.0.689504179249.issue37955@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 40c080934b3d49311209b1cb690c2ea1e04df7e7 by Chris Withers (Paulo Henrique Silva) in branch 'master':
bpo-37955: correct mock.patch docs with respect to the returned type (GH-15521)
https://github.com/python/cpython/commit/40c080934b3d49311209b1cb690c2ea1e04df7e7


----------
nosy: +cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37955>
_______________________________________

From report at bugs.python.org  Sat Jan 25 05:54:09 2020
From: report at bugs.python.org (Chris Withers)
Date: Sat, 25 Jan 2020 10:54:09 +0000
Subject: [issue37955] mock.patch incorrect reference to Mock
In-Reply-To: <1566832308.08.0.460509709565.issue37955@roundup.psfhosted.org>
Message-ID: <1579949649.01.0.853143809536.issue37955@roundup.psfhosted.org>


Change by Chris Withers <chris at withers.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37955>
_______________________________________

From report at bugs.python.org  Sat Jan 25 06:37:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 25 Jan 2020 11:37:53 +0000
Subject: [issue39388] IDLE: Changes to keybindings aren't reverted on cancel
In-Reply-To: <1579454814.83.0.214082959531.issue39388@roundup.psfhosted.org>
Message-ID: <1579952273.83.0.492598939881.issue39388@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39388>
_______________________________________

From report at bugs.python.org  Sat Jan 25 06:48:44 2020
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 25 Jan 2020 11:48:44 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1579952924.45.0.816781215418.issue12915@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> With the lack of support, I suggest closing this.

Well, the lack of support is just for adding to importlib. It still seems useful to refactor it out ... just not clear where the best place is. Perhaps pkgutil? It's definitely useful to have in the stdlib in one place. I'll come up with a PR soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Sat Jan 25 07:49:41 2020
From: report at bugs.python.org (daniel hahler)
Date: Sat, 25 Jan 2020 12:49:41 +0000
Subject: [issue37022] pdb: do_p and do_pp swallow exceptions from __repr__
In-Reply-To: <1558627334.31.0.41290624509.issue37022@roundup.psfhosted.org>
Message-ID: <1579956581.56.0.689320684761.issue37022@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
keywords: +patch
pull_requests: +17564
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18180

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37022>
_______________________________________

From report at bugs.python.org  Sat Jan 25 08:18:38 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 25 Jan 2020 13:18:38 +0000
Subject: [issue33973] HTTP request-line parsing splits on Unicode whitespace
In-Reply-To: <1530038369.47.0.56676864532.issue33973@psf.upfronthosting.co.za>
Message-ID: <1579958318.1.0.736356087953.issue33973@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions: +Python 3.9 -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33973>
_______________________________________

From report at bugs.python.org  Sat Jan 25 08:38:12 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 25 Jan 2020 13:38:12 +0000
Subject: [issue38580] select()'s documentation claims only sequences are
 accepted, but it allows all iterables
In-Reply-To: <1571915326.93.0.150606644361.issue38580@roundup.psfhosted.org>
Message-ID: <1579959492.73.0.831545594672.issue38580@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38580>
_______________________________________

From report at bugs.python.org  Sat Jan 25 09:00:07 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 25 Jan 2020 14:00:07 +0000
Subject: [issue39452] Improve the __main__ module documentation
Message-ID: <1579960807.69.0.285569916248.issue39452@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

This PR will apply the following changes on the [`__main__` module documentation](https://docs.python.org/3.7/library/__main__.html):

- correct the phrase "run as script" by "run from the file system" (as used in the [`runpy`](https://docs.python.org/3/library/runpy.html) documentation) since "run as script" does not mean the intended `python foo.py` but `python -m foo` (cf. [PEP 338](https://www.python.org/dev/peps/pep-0338/));
- replace the phrase "run with `-m`" by "run from the module namespace" (as used in the [`runpy`](https://docs.python.org/3/library/runpy.html) documentation) since the module can be equivalently run with `runpy.run_module('foo')` instead of `python -m foo`;
- make the block comment [PEP 8](https://www.python.org/dev/peps/pep-0008/#comments)-compliant (located before the `if` block, capital initialised, period ended);
- add a missing case for which a package's \_\_main\_\_.py is executed (when the package is run from the file system: `python foo/`).

----------
assignee: docs at python
components: Documentation
messages: 360682
nosy: docs at python, maggyero
priority: normal
pull_requests: 17565
severity: normal
status: open
title: Improve the __main__ module documentation
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39452>
_______________________________________

From report at bugs.python.org  Sat Jan 25 09:03:45 2020
From: report at bugs.python.org (Sebastian G Pedersen)
Date: Sat, 25 Jan 2020 14:03:45 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
In-Reply-To: <1579776260.84.0.333075912412.issue39380@roundup.psfhosted.org>
Message-ID: <1579961025.04.0.408733586319.issue39380@roundup.psfhosted.org>


Sebastian G Pedersen <sebastian.g.pedersen at gmail.com> added the comment:

Thank you for the feedback.

I will elaborate a little bit on the reasons and thoughts behind the pull request:
Since RFC 2640, the industry standard within FTP Clients is UTF-8 (see e.g. FileZilla here: https://wiki.filezilla-project.org/Character_Encoding, or WinSCP here: https://winscp.net/eng/docs/faq_utf8).

Given this, I believe the majority of the users that have not investigated the code wrongly assumes UTF-8 encoding for ftplib as well (as it is now).

I am new to contributing, and not sure, how much deprecation warnings are used (I simply followed the previous encoding change on ftplib), so I will change it based on the feedback. However, shouldn't it be a FutureWarning, so it will be reported by default at initialisation?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Sat Jan 25 09:05:57 2020
From: report at bugs.python.org (Hugo Ricateau)
Date: Sat, 25 Jan 2020 14:05:57 +0000
Subject: [issue39443] Inhomogeneous behaviour for descriptors in between the
 class-instance and metaclass-class pairs
In-Reply-To: <1579879054.45.0.122838509696.issue39443@roundup.psfhosted.org>
Message-ID: <1579961157.27.0.584075416812.issue39443@roundup.psfhosted.org>


Hugo Ricateau <hugo.ricateau at gmail.com> added the comment:

Thanks for this detailed answer; very instructive :)

> the descriptor protocol is only triggered by "dotted access"

Indeed; this is what I was missing... despite it is indirectly mentioned in the documentation. Nonetheless, it could be worth the overload to explicitly add in the language reference that 'the descriptor protocol is only triggered by "dotted access"' (looks like it is not the case for now).

>    + a list enumerating places where descriptors are *not* invoked
> [...]
> Which of those do you think would have helped you the most?

Could be really helpful as well, by clearly exhibiting the limitations of the descriptors; I think the best location for this could be the 'descriptors howto' page despite the other option is perfectly suitable as well.

Best,
Hugo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39443>
_______________________________________

From report at bugs.python.org  Sat Jan 25 09:22:26 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 25 Jan 2020 14:22:26 +0000
Subject: [issue39453] Use-after-free in list contain
Message-ID: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

class poc() :
    def __eq__(self,other) :
        l.clear()
        return NotImplemented

l = [poc(), poc(), poc()]
3 in l

[1]    2606 segmentation fault

sigh..

----------
assignee: corona10
messages: 360686
nosy: corona10, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: Use-after-free in list contain
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Sat Jan 25 09:22:50 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 25 Jan 2020 14:22:50 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1579962170.6.0.338920048312.issue39453@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I will send a patch ASAP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Sat Jan 25 09:33:07 2020
From: report at bugs.python.org (Iustin Pop)
Date: Sat, 25 Jan 2020 14:33:07 +0000
Subject: [issue37465] Incorrect documentation for `s#` arguments in C API
 argument parsing
In-Reply-To: <1561969220.64.0.698927964651.issue37465@roundup.psfhosted.org>
Message-ID: <1579962787.48.0.817030436211.issue37465@roundup.psfhosted.org>


Change by Iustin Pop <iustin at k1024.org>:


----------
keywords: +patch
pull_requests: +17566
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17478

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37465>
_______________________________________

From report at bugs.python.org  Sat Jan 25 09:53:11 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jan 2020 14:53:11 +0000
Subject: [issue38473] AttributeError on asserting autospecced mock object
 added using attach_mock
In-Reply-To: <1571063109.86.0.136370910863.issue38473@roundup.psfhosted.org>
Message-ID: <1579963991.68.0.722553662684.issue38473@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:


New changeset a5906b2bfce9560568dee1dcc3550e74e742dd34 by Karthikeyan Singaravelan (Miss Islington (bot)) in branch '3.8':
bpo-38473: Handle autospecced functions and methods used with attach_mock (GH-16784) (GH-18167)
https://github.com/python/cpython/commit/a5906b2bfce9560568dee1dcc3550e74e742dd34


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38473>
_______________________________________

From report at bugs.python.org  Sat Jan 25 09:55:01 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jan 2020 14:55:01 +0000
Subject: [issue38473] AttributeError on asserting autospecced mock object
 added using attach_mock
In-Reply-To: <1571063109.86.0.136370910863.issue38473@roundup.psfhosted.org>
Message-ID: <1579964101.11.0.787684762096.issue38473@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:


New changeset 71d2b3344f4560ffee14fccd320b20e7add50fec by Karthikeyan Singaravelan (Miss Islington (bot)) in branch '3.7':
bpo-38473: Handle autospecced functions and methods used with attach_mock (GH-16784) (#18166)
https://github.com/python/cpython/commit/71d2b3344f4560ffee14fccd320b20e7add50fec


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38473>
_______________________________________

From report at bugs.python.org  Sat Jan 25 09:56:39 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 25 Jan 2020 14:56:39 +0000
Subject: [issue38473] AttributeError on asserting autospecced mock object
 added using attach_mock
In-Reply-To: <1571063109.86.0.136370910863.issue38473@roundup.psfhosted.org>
Message-ID: <1579964199.85.0.682480935941.issue38473@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thank you all for the review. Closing it as fixed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38473>
_______________________________________

From report at bugs.python.org  Sat Jan 25 09:53:27 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 25 Jan 2020 14:53:27 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1579964007.88.0.621122308426.issue39453@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17567
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18181

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Sat Jan 25 10:17:41 2020
From: report at bugs.python.org (YPf)
Date: Sat, 25 Jan 2020 15:17:41 +0000
Subject: [issue39454] when \\u in byte_string ,
 byte_string.decode('raw_unicode_escape') maybe has problem
Message-ID: <1579965461.7.0.207168437905.issue39454@roundup.psfhosted.org>


New submission from YPf <yayiba1223 at 163.com>:

>>> path=r'C:\Users\Administrator\Desktop'
>>> path.encode('raw_unicode_escape')
b'C:\\Users\\Administrator\\Desktop'
>>> path.encode('raw_unicode_escape').decode('raw_unicode_escape')
Traceback (most recent call last):
  File "<pyshell#48>", line 1, in <module>
    path.encode('raw_unicode_escape').decode('raw_unicode_escape')
UnicodeDecodeError: 'rawunicodeescape' codec can't decode bytes in position 2-3: truncated \UXXXXXXXX escape

----------
messages: 360691
nosy: yayiba1223
priority: normal
severity: normal
status: open
title: when \\u in byte_string ,byte_string.decode('raw_unicode_escape') maybe has problem
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39454>
_______________________________________

From report at bugs.python.org  Sat Jan 25 10:36:04 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 25 Jan 2020 15:36:04 +0000
Subject: [issue39454] when \\u in byte_string ,
 byte_string.decode('raw_unicode_escape') maybe has problem
In-Reply-To: <1579965461.7.0.207168437905.issue39454@roundup.psfhosted.org>
Message-ID: <1579966564.59.0.527061623515.issue39454@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Why are you using this type of encoding on this bytes object? It specifically says in its description that "Existing backslashes are not escaped in any way.". If you'd use unicode_escape instead, you would be able to round-trip back to your original string.

----------
components: +Unicode
nosy: +SilentGhost, ezio.melotti, vstinner
status: open -> pending
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39454>
_______________________________________

From report at bugs.python.org  Sat Jan 25 10:44:49 2020
From: report at bugs.python.org (Chris Withers)
Date: Sat, 25 Jan 2020 15:44:49 +0000
Subject: [issue38932] unittest.mock.Mock.reset_mocks does not pass all
 arguments to its children
In-Reply-To: <1574884766.44.0.780090732457.issue38932@roundup.psfhosted.org>
Message-ID: <1579967089.52.0.112570889073.issue38932@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset aef7dc89879d099dc704bd8037b8a7686fb72838 by Chris Withers (Vegard Stikbakke) in branch 'master':
bpo-38932: Mock fully resets child objects on reset_mock(). (GH-17409)
https://github.com/python/cpython/commit/aef7dc89879d099dc704bd8037b8a7686fb72838


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38932>
_______________________________________

From report at bugs.python.org  Sat Jan 25 10:46:39 2020
From: report at bugs.python.org (Chris Withers)
Date: Sat, 25 Jan 2020 15:46:39 +0000
Subject: [issue38932] unittest.mock.Mock.reset_mocks does not pass all
 arguments to its children
In-Reply-To: <1574884766.44.0.780090732457.issue38932@roundup.psfhosted.org>
Message-ID: <1579967199.66.0.406799538897.issue38932@roundup.psfhosted.org>


Change by Chris Withers <chris at withers.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38932>
_______________________________________

From report at bugs.python.org  Sat Jan 25 10:52:24 2020
From: report at bugs.python.org (Aurora)
Date: Sat, 25 Jan 2020 15:52:24 +0000
Subject: [issue39449] New Assignment operator
In-Reply-To: <1579907630.13.0.450663882045.issue39449@roundup.psfhosted.org>
Message-ID: <1579967544.29.0.640824041703.issue39449@roundup.psfhosted.org>


Aurora <auroralanes at pm.me> added the comment:

That's a nice simple idea.

----------
nosy: +opensource-assist

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39449>
_______________________________________

From report at bugs.python.org  Sat Jan 25 11:07:22 2020
From: report at bugs.python.org (SilentGhost)
Date: Sat, 25 Jan 2020 16:07:22 +0000
Subject: [issue39449] New Assignment operator
In-Reply-To: <1579907630.13.0.450663882045.issue39449@roundup.psfhosted.org>
Message-ID: <1579968442.87.0.999474666347.issue39449@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39449>
_______________________________________

From report at bugs.python.org  Sat Jan 25 11:10:06 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 25 Jan 2020 16:10:06 +0000
Subject: [issue39452] Improve the __main__ module documentation
In-Reply-To: <1579960807.69.0.285569916248.issue39452@roundup.psfhosted.org>
Message-ID: <1579968606.54.0.0655728203879.issue39452@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

There are some serious problems with the PR.

You state that these two phrases are from the runpy documentation:

* "run from the module namespace"
* "run from the file system"

but neither of those phrases appear in the runpy documentation here:

https://docs.python.org/3/library/runpy.html

You also say:

> "run as script" does not mean the intended `python foo.py` 
> but `python -m foo`

but this is incorrect, and I think based on a misunderstanding of PEP 338. The title of PEP 338, "Executing modules as scripts", is not exclusive: the PEP is about the -m mechanism for *locating the module* in order to run it as a script. It doesn't imply that `python spam.py` should no longer be considered to be running a script.

In common parlance, "run as a script" certainly does include the case where you specify the module by filename `python spam.py` as well as the -m case where you specify it as a module name and let the interpreter locate the file. In other words, both

    python pathname/spam.py
    python -m spam

are correctly described as "running spam.py as a script" (and other variations). They differ in how the script is specified, but both mechanisms treat the spam.py file as a script and run it.

See for example https://duckduckgo.com/?q=how+to+run+a+python+script for examples of common usage.

Consequently, it is simply wrong to say that the intended usage of "run a script" is the -m mechanism.

The PR changes the term "scope" to "environment", but I think that is wrong. An environment is potentially greater than a scope. `__main__` is a module namespace, hence a scope. The environment includes things outside of that scope, such as the builtins, environment variables, the current working directory, the python path, etc. We don't talk about modules being an environment, but as making up a scope.

The PR introduces the phrase "when the module is run from the file system" to mean the case where a script is run using `python spam.py`, but it equally applies to the case of `python -m spam`. In both cases, spam is located somewhere in the file system.

(It is conceivable that -m could locate and run a built-in module, but I don't know any cases where that actually works. Even if it does, we surely don't need to complicate the docs for this corner case. It's enough to know that -m will locate the module and run it.)

The PR describes three cases: running from the file system, running from stdin, and running "from the module namespace" but that last one is a clumsy phrase which, it seems to me, is not correct. How do you run a module from its own namespace? Modules *are* a namespace, and we say code runs *in* a namespace, not "from" it.

In any case, it doesn't matter whether the script is specified on the command line as a file name, or as a module name with -m, or double-clicked in a GUI, in all three cases the module's code is executed in the module's namespace.

So it is wrong to distinguish "from the file system" and "from (in) the module namespace" as two distinct cases. They are the same case.

The PR replaces the comment inside the `if` block:

    # execute only if run as a script

with a comment above the `if` statement:

    # Execute only if the module is not imported.

but the new comment is factually incorrect on two counts. Firstly, it is not correct that the `if` statement executes only if the module is not imported. There is no magic to the `if` statement. It always executes, regardless of whether the module is being run as a script or not. We can write code like this:

    if print("Hello, this always runs!") or __name__ == '__main__':
        # execute only if run as a script
        print('running as a script')
    else:
        # execute only if *not* run as a script
        print('not run as a script')

Placing the comment above the `if`, where it will apply to the entire `if` statement, is incorrect.

The second problem is that when running a module with -m it *is* imported. PEP 338 is clear about this:

"if -m is used to execute a module the PEP 302 import mechanisms are used to locate the module and retrieve its compiled code, before executing the module"

(in other words: import the module). We can test this, for example, if you create a package:

    spam/
    +-- __init__.py
    +-- eggs.py

and then run `python -m spam.eggs`, not only `__main__` (the eggs.py module) but also `spam` will be found in sys.modules. So the new comment is simply wrong.

There may be other issues with the PR.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39452>
_______________________________________

From report at bugs.python.org  Sat Jan 25 11:38:28 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 25 Jan 2020 16:38:28 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
In-Reply-To: <1579776260.84.0.333075912412.issue39380@roundup.psfhosted.org>
Message-ID: <1579970308.91.0.678130421508.issue39380@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

It's been a long time since I implemented UTF-8 support in pyftpdlib, but long story short is that:
- most recent servers are supposed to use UTF-8 by default
- such servers must include "UTF-8" in the FEAT command response
- some servers may enable UTF-8 only if client explicitly sends "OPTS UTF-8 ON" first, but that is based on an draft RFC. Server implementors usually treat this command as a no-op and simply assume UTF-8 as the default.

With that said, I am -1 about implementing logic based on FEAT/OPTS: that should be done before login, and at that point some servers may erroneously reject any command other than USER, PASS and ACCT. 

Personally I think it makes more sense to just use UTF-8 without going through a deprecation period, document *encoding* attribute and mention that in order to deal with servers not supporting UTF8 you can pre-emptively check FEAT response and set ASCII encoding. But I am not a unicode expert, so I would like to hear some other opinion re. the implications of going from latin-1 to utf8 in terms of potential code breakage.

----------
nosy: +benjamin.peterson, ezio.melotti, lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Sat Jan 25 13:50:03 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jan 2020 18:50:03 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1579978203.4.0.981813620445.issue15243@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 7de617455ed788e6730c40cf854c4b72b0432194 by Berker Peksag (alclarks) in branch 'master':
bpo-15243: Document __prepare__ as classmethod (GH-17124)
https://github.com/python/cpython/commit/7de617455ed788e6730c40cf854c4b72b0432194


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15243>
_______________________________________

From report at bugs.python.org  Sat Jan 25 13:50:13 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jan 2020 18:50:13 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1579978213.03.0.592496121462.issue15243@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17568
pull_request: https://github.com/python/cpython/pull/18185

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15243>
_______________________________________

From report at bugs.python.org  Sat Jan 25 13:50:19 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jan 2020 18:50:19 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1579978219.24.0.523474849484.issue15243@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17569
pull_request: https://github.com/python/cpython/pull/18186

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15243>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:04:20 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jan 2020 19:04:20 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1579979060.25.0.679681160259.issue15243@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 321491a536c378227f9d574703f7c06f89c67dcf by Berker Peksag (Miss Islington (bot)) in branch '3.8':
bpo-15243: Document __prepare__ as classmethod (GH-17124)
https://github.com/python/cpython/commit/321491a536c378227f9d574703f7c06f89c67dcf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15243>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:04:59 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jan 2020 19:04:59 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1579979099.24.0.739447707519.issue15243@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 548685e364af3d366d3aef924b2077ee6f8d13dc by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-15243: Document __prepare__ as classmethod (GH-17124)
https://github.com/python/cpython/commit/548685e364af3d366d3aef924b2077ee6f8d13dc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15243>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:05:38 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jan 2020 19:05:38 +0000
Subject: [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1579979138.76.0.998848407985.issue15243@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15243>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:23:03 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jan 2020 19:23:03 +0000
Subject: [issue36654] Add example to tokenize.tokenize
In-Reply-To: <1555559036.7.0.0522143852215.issue36654@roundup.psfhosted.org>
Message-ID: <1579980183.57.0.860432430649.issue36654@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 4b09dc79f4d08d85f2cc945563e9c8ef1e531d7b by Berker Peksag (Windson yang) in branch 'master':
bpo-36654: Add examples for using tokenize module programmically (#12947)
https://github.com/python/cpython/commit/4b09dc79f4d08d85f2cc945563e9c8ef1e531d7b


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36654>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:23:12 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jan 2020 19:23:12 +0000
Subject: [issue36654] Add example to tokenize.tokenize
In-Reply-To: <1555559036.7.0.0522143852215.issue36654@roundup.psfhosted.org>
Message-ID: <1579980192.78.0.378870292555.issue36654@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17570
pull_request: https://github.com/python/cpython/pull/18187

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36654>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:23:19 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 25 Jan 2020 19:23:19 +0000
Subject: [issue36654] Add example to tokenize.tokenize
In-Reply-To: <1555559036.7.0.0522143852215.issue36654@roundup.psfhosted.org>
Message-ID: <1579980199.9.0.702728959674.issue36654@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17571
pull_request: https://github.com/python/cpython/pull/18188

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36654>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:34:40 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jan 2020 19:34:40 +0000
Subject: [issue36654] Add example to tokenize.tokenize
In-Reply-To: <1555559036.7.0.0522143852215.issue36654@roundup.psfhosted.org>
Message-ID: <1579980880.53.0.968730992552.issue36654@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 1cf0df4f1bcc38dfd70a152af20cf584de531ea7 by Berker Peksag (Miss Islington (bot)) in branch '3.8':
bpo-36654: Add examples for using tokenize module programmatically (GH-18187)
https://github.com/python/cpython/commit/1cf0df4f1bcc38dfd70a152af20cf584de531ea7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36654>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:36:07 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jan 2020 19:36:07 +0000
Subject: [issue36654] Add example to tokenize.tokenize
In-Reply-To: <1555559036.7.0.0522143852215.issue36654@roundup.psfhosted.org>
Message-ID: <1579980967.85.0.512585343139.issue36654@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 6dbd843dedc9e05c0e3f4714294837f0a83deebe by Berker Peksag (Miss Islington (bot)) in branch '3.7':
bpo-36654: Add examples for using tokenize module programmatically (GH-12947)
https://github.com/python/cpython/commit/6dbd843dedc9e05c0e3f4714294837f0a83deebe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36654>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:37:04 2020
From: report at bugs.python.org (R. David Murray)
Date: Sat, 25 Jan 2020 19:37:04 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1579981024.04.0.100736627361.issue10740@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please open a new issue for this question.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:40:04 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jan 2020 19:40:04 +0000
Subject: [issue36654] Add example to tokenize.tokenize
In-Reply-To: <1555559036.7.0.0522143852215.issue36654@roundup.psfhosted.org>
Message-ID: <1579981204.44.0.0732301133035.issue36654@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Wow, I managed to make typos in all three commits!

PR 12947 has some discussion about why adding these examples would be a good idea as we now have two different APIs for unicode and bytes input.

Thanks for the PR, Windson.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36654>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:40:31 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 25 Jan 2020 19:40:31 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
In-Reply-To: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>
Message-ID: <1579981231.12.0.417905764267.issue39234@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset eec7636bfd07412b5872c0683636e9e98bf79a8c by Ned Deily (Miss Islington (bot)) in branch '3.8':
bpo-39234: Doc: `enum.auto()` incrementation value not specified. (GH-17872) (GH-17875)
https://github.com/python/cpython/commit/eec7636bfd07412b5872c0683636e9e98bf79a8c


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39234>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:41:28 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 25 Jan 2020 19:41:28 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
In-Reply-To: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>
Message-ID: <1579981288.83.0.0476906562174.issue39234@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset b0a6ec256b460f071e33b4633e5bec450d8e6394 by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-39234: Doc: `enum.auto()` incrementation value not specified. (GH-17872) (GH-17876)
https://github.com/python/cpython/commit/b0a6ec256b460f071e33b4633e5bec450d8e6394


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39234>
_______________________________________

From report at bugs.python.org  Sat Jan 25 14:41:57 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 25 Jan 2020 19:41:57 +0000
Subject: [issue39234] `enum.auto()` incrementation value not specified.
In-Reply-To: <1578337839.24.0.759731756128.issue39234@roundup.psfhosted.org>
Message-ID: <1579981317.49.0.00525494559012.issue39234@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39234>
_______________________________________

From report at bugs.python.org  Sat Jan 25 15:00:23 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jan 2020 20:00:23 +0000
Subject: [issue39309] Please delete my account
In-Reply-To: <1579351769.04.0.498329028577.issue39309@roundup.psfhosted.org>
Message-ID: <1579982423.7.0.872987371499.issue39309@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I can remove OP's User role and change their user name etc. to make it anonymize as much as possible. I cannot get into the server so perhaps Ernest can delete the account.

----------
nosy: +EWDurbin, berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39309>
_______________________________________

From report at bugs.python.org  Sat Jan 25 15:21:00 2020
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 25 Jan 2020 20:21:00 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579983660.35.0.904605398956.issue39430@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

In msg360620 Serhiy wrote:
> When the interpreter encounters "import foo" in bar.py, the import machinery takes the module foo from sys.modules.
> So you break an infinite cycle and can import modules with cyclic dependencies.

The following pdb session that is run when executing the foo.py script, shows that this is not quite accurate.  When the interpreter encounters "import foo" in bar.py, the import machinery instead starts executing foo.py once again and detects that at line 9 of foo.py the 'import bar' statement does not have to be executed since the import machinery is already in the process of importing this module.  So it is at that point that the infinite cycle is broken.
Later on line 12 in foo.py the import machinery detects that the AttributeError is raised because of a circular import and warns that "partially initialized module 'bar' has no attribute 'BAR' (most likely due to a circular import)".

$ cat -n foo.py
     1  import pdb
     2  debug = 1
     3
     4  # Prevent starting a new pdb session when foo is imported by bar.
     5  if debug and not hasattr(pdb, 'is_pdb_started'):
     6      pdb.Pdb(skip=['importlib*']).set_trace()
     7      pdb.is_pdb_started = True
     8
     9  import bar
    10  FOO = 'foo'
    11  try:
    12      print(bar.BAR)
    13  except AttributeError as e:
    14      # The exception is raised with an explicit reason when foo is imported by
    15      # bar due to partially initialized module 'bar'.
    16      print(e)

$ cat -n bar.py
     1  import foo
     2  BAR = 'bar'
     3  print(foo.FOO)

$ python foo.py
> /tmp/foo.py(7)<module>()
-> pdb.is_pdb_started = True
(Pdb) step
> /tmp/foo.py(9)<module>()
-> import bar
(Pdb) step
--Call--
> /tmp/bar.py(1)<module>()
-> import foo
(Pdb) step
> /tmp/bar.py(1)<module>()
-> import foo
(Pdb) step
--Call--
> /tmp/foo.py(1)<module>()
-> import pdb
(Pdb) step
> /tmp/foo.py(1)<module>()
-> import pdb
(Pdb) step
> /tmp/foo.py(2)<module>()
-> debug = 1
(Pdb) step
> /tmp/foo.py(5)<module>()
-> if debug and not hasattr(pdb, 'is_pdb_started'):
(Pdb) step
> /tmp/foo.py(9)<module>()
-> import bar
(Pdb) step
> /tmp/foo.py(10)<module>()
-> FOO = 'foo'
(Pdb) step
> /tmp/foo.py(11)<module>()
-> try:
(Pdb) step
> /tmp/foo.py(12)<module>()
-> print(bar.BAR)
(Pdb) step
AttributeError: partially initialized module 'bar' has no attribute 'BAR' (most likely due to a circular import)
> /tmp/foo.py(12)<module>()
-> print(bar.BAR)
(Pdb) step
> /tmp/foo.py(13)<module>()
-> except AttributeError as e:
(Pdb) step
> /tmp/foo.py(16)<module>()
-> print(e)
(Pdb) step
partially initialized module 'bar' has no attribute 'BAR' (most likely due to a circular import)
--Return--
> /tmp/foo.py(16)<module>()->None
-> print(e)
(Pdb) step
> /tmp/bar.py(2)<module>()
-> BAR = 'bar'
(Pdb) step
> /tmp/bar.py(3)<module>()
-> print(foo.FOO)
(Pdb) step
foo
--Return--
> /tmp/bar.py(3)<module>()->None
-> print(foo.FOO)
(Pdb) step
> /tmp/foo.py(10)<module>()
-> FOO = 'foo'
(Pdb) step
> /tmp/foo.py(11)<module>()
-> try:
(Pdb) step
> /tmp/foo.py(12)<module>()
-> print(bar.BAR)
(Pdb) step
bar
--Return--
> /tmp/foo.py(12)<module>()->None
-> print(bar.BAR)
(Pdb) step
$

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Sat Jan 25 15:27:32 2020
From: report at bugs.python.org (Aurora)
Date: Sat, 25 Jan 2020 20:27:32 +0000
Subject: [issue39455] Update the documentation for linecache module
Message-ID: <1579984052.28.0.0961825166353.issue39455@roundup.psfhosted.org>


New submission from Aurora <auroralanes at pm.me>:

Added the definitions for two undocumented functions.

----------
assignee: docs at python
components: Documentation
messages: 360709
nosy: docs at python, opensource-assist
priority: normal
pull_requests: 17572
severity: normal
status: open
title: Update the documentation for linecache module
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39455>
_______________________________________

From report at bugs.python.org  Sat Jan 25 15:48:50 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 25 Jan 2020 20:48:50 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1579985330.87.0.533403448235.issue12915@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

FTR, Django has a similar helper:

    from django.utils.module_loading import import_string

    ValidationError = import_string('django.core.exceptions.ValidationError')

https://docs.djangoproject.com/en/3.0/ref/utils/#django.utils.module_loading.import_string

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Sat Jan 25 15:56:29 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jan 2020 20:56:29 +0000
Subject: [issue39443] Inhomogeneous behaviour for descriptors in between the
 class-instance and metaclass-class pairs
In-Reply-To: <1579879054.45.0.122838509696.issue39443@roundup.psfhosted.org>
Message-ID: <1579985789.27.0.297186477227.issue39443@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger
components: +Documentation -Interpreter Core
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39443>
_______________________________________

From report at bugs.python.org  Sat Jan 25 16:05:15 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jan 2020 21:05:15 +0000
Subject: [issue39446] Documentation should reflect that all dicts are now
 ordered
In-Reply-To: <1579894070.69.0.0178320617027.issue39446@roundup.psfhosted.org>
Message-ID: <1579986315.97.0.565439780656.issue39446@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This is already covered here:
  https://docs.python.org/3/library/stdtypes.html#dict
and here:
  https://docs.python.org/3/library/collections.html#ordereddict-objects

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39446>
_______________________________________

From report at bugs.python.org  Sat Jan 25 16:07:23 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jan 2020 21:07:23 +0000
Subject: [issue24928] mock.patch.dict spoils order of items in
 collections.OrderedDict
In-Reply-To: <1440443995.19.0.0795335566212.issue24928@psf.upfronthosting.co.za>
Message-ID: <1579986443.31.0.316707957759.issue24928@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24928>
_______________________________________

From report at bugs.python.org  Sat Jan 25 16:14:23 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jan 2020 21:14:23 +0000
Subject: [issue39165] Completeness and symmetry in RE, avoid `findall(...)[0]`
In-Reply-To: <1577711945.6.0.0241743491206.issue39165@roundup.psfhosted.org>
Message-ID: <1579986863.29.0.543585793135.issue39165@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Serhiy and Terry.  Marking this as "closed/rejected".  

Adding more-ways-to-it usually doesn't make users better-off (more to learn, more to remember, more to choose from, creating a new question about whether or not to use re.search(), creating another inter-version API difference, etc.)

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39165>
_______________________________________

From report at bugs.python.org  Sat Jan 25 16:27:05 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jan 2020 21:27:05 +0000
Subject: [issue39451] enum.Enum reference count leaks
In-Reply-To: <1579933833.85.0.945475764886.issue39451@roundup.psfhosted.org>
Message-ID: <1579987625.67.0.210002587645.issue39451@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> ethan.furman
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39451>
_______________________________________

From report at bugs.python.org  Sat Jan 25 17:19:09 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 25 Jan 2020 22:19:09 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
In-Reply-To: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>
Message-ID: <1579990749.41.0.191108877799.issue39374@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 8271441d8b6e1f8eae1457c437da24e775801d9f by Raymond Hettinger (Juhana Jauhiainen) in branch 'master':
bpo-39374: Updated sorting documentation (GH-18177)
https://github.com/python/cpython/commit/8271441d8b6e1f8eae1457c437da24e775801d9f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39374>
_______________________________________

From report at bugs.python.org  Sat Jan 25 18:24:38 2020
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 25 Jan 2020 23:24:38 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1579994678.72.0.580441980109.issue39430@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

This fixed the bug.

To reproduce the bug, substitute the "from _lzma import *" statement with "raise ImportError"
in Lib/lzma.py to simulate that the _lzma module is missing and run the test.py script written and uploaded by Maciej.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Sat Jan 25 20:21:23 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 26 Jan 2020 01:21:23 +0000
Subject: [issue38337] inspect: getmembers calls properties
In-Reply-To: <1569931319.11.0.161787180553.issue38337@roundup.psfhosted.org>
Message-ID: <1580001683.42.0.671925411325.issue38337@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Here is a link to the discussion of this on ideas:
https://discuss.python.org/t/implement-inspect-getmembers-static/2550

----------
nosy: +cheryl.sabella
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38337>
_______________________________________

From report at bugs.python.org  Sat Jan 25 20:33:42 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 26 Jan 2020 01:33:42 +0000
Subject: [issue29757] The loop in utility `socket.create_connection()`
 swallows previous errors
In-Reply-To: <1488984317.87.0.296010902983.issue29757@psf.upfronthosting.co.za>
Message-ID: <1580002422.25.0.400664099607.issue29757@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions: +Python 3.9 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29757>
_______________________________________

From report at bugs.python.org  Sat Jan 25 20:45:32 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 26 Jan 2020 01:45:32 +0000
Subject: [issue39400] pydoc: Use of MANPAGER variable is incorrect
In-Reply-To: <1579554143.61.0.454786328579.issue39400@roundup.psfhosted.org>
Message-ID: <1580003132.92.0.199877353032.issue39400@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39400>
_______________________________________

From report at bugs.python.org  Sat Jan 25 20:54:56 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 26 Jan 2020 01:54:56 +0000
Subject: [issue9216] FIPS support for hashlib
In-Reply-To: <1278721335.16.0.522410247151.issue9216@psf.upfronthosting.co.za>
Message-ID: <1580003696.4.0.810079415426.issue9216@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Should this issue be closed as resolved?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9216>
_______________________________________

From report at bugs.python.org  Sat Jan 25 21:33:44 2020
From: report at bugs.python.org (Matt Kokotovich)
Date: Sun, 26 Jan 2020 02:33:44 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
In-Reply-To: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>
Message-ID: <1580006024.13.0.910344734993.issue39082@roundup.psfhosted.org>


Change by Matt Kokotovich <mkokotovich at gmail.com>:


----------
pull_requests: +17573
pull_request: https://github.com/python/cpython/pull/18190

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Sat Jan 25 22:07:22 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jan 2020 03:07:22 +0000
Subject: [issue39374] Key in sort -> Callable Object instead of function
In-Reply-To: <1579302682.83.0.203843605883.issue39374@roundup.psfhosted.org>
Message-ID: <1580008042.47.0.51569529707.issue39374@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39374>
_______________________________________

From report at bugs.python.org  Sat Jan 25 22:27:05 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jan 2020 03:27:05 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1580009225.21.0.70580457558.issue36018@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +17574
pull_request: https://github.com/python/cpython/pull/18191

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Sat Jan 25 23:21:22 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jan 2020 04:21:22 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1580012482.02.0.305013458352.issue36018@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 10355ed7f132ed10f1e0d8bd64ccb744b86b1cce by Raymond Hettinger in branch 'master':
bpo-36018: Add another example for NormalDist() (#18191)
https://github.com/python/cpython/commit/10355ed7f132ed10f1e0d8bd64ccb744b86b1cce


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Sat Jan 25 23:21:31 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 26 Jan 2020 04:21:31 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1580012491.14.0.927674815019.issue36018@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17575
pull_request: https://github.com/python/cpython/pull/18192

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Sat Jan 25 23:50:10 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jan 2020 04:50:10 +0000
Subject: [issue36350] inspect.Signature.parameters and
 inspect.BoundArguments.arguments should be dicts instead of OrderedDicts
In-Reply-To: <1552922208.92.0.691129185173.issue36350@roundup.psfhosted.org>
Message-ID: <1580014210.31.0.922348775933.issue36350@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'm neutral on whether to move this forward or not.  Usually, we would only make an externally visible and possibly consequential API change if there were some compensating benefit to users (a significant speed-up for example).

Also note that the existing code uses move_to_end() so there is some case to be made that OrderedDict() was a reasonable choice even if dict() had been an option from the outset.

I suggest leaving this as-is.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36350>
_______________________________________

From report at bugs.python.org  Sun Jan 26 00:24:17 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jan 2020 05:24:17 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1580016257.58.0.0376730550788.issue36018@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset eebcff8c071b38b53bd429892524ba8518cbeb98 by Raymond Hettinger (Miss Islington (bot)) in branch '3.8':
bpo-36018: Add another example for NormalDist() (GH-18191) (GH-18192)
https://github.com/python/cpython/commit/eebcff8c071b38b53bd429892524ba8518cbeb98


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Sun Jan 26 01:04:03 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jan 2020 06:04:03 +0000
Subject: [issue39443] Inhomogeneous behaviour for descriptors in between the
 class-instance and metaclass-class pairs
In-Reply-To: <1579879054.45.0.122838509696.issue39443@roundup.psfhosted.org>
Message-ID: <1580018643.12.0.263255341081.issue39443@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Some thoughts:

* The docs talk about descriptor invocation from "attribute access".  The reason they don't say "dotted access" is that the descriptors can be invoked in multiple ways: dotted access, getattr()/setattr() functions, super(), or direct calls to __getattribute__().

* From the point-of-view of descriptors, metaclasses aren't special.  The only essential fact needed is that type.__getattribute__() is called instead of object.__getattribute__().  The how-to guide already discusses how those methods differ.

* For now, I'm inclined to leave the docs as-is.  The existing coverage of common cases is already a bit hard to read.  It could become less readable if we list places where something doesn't happen, warnings to avoid features, or detailed explanations of uncommon cases like mixing metaclasses with descriptors.  If this arises again, we could add a FAQ entry of some such.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39443>
_______________________________________

From report at bugs.python.org  Sun Jan 26 01:07:31 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jan 2020 06:07:31 +0000
Subject: [issue11549] Build-out an AST optimizer,
 moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1580018851.72.0.520542918758.issue11549@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think this particular issue can be closed in now.  After it was written, the AST optimizer has been built-out and some peephole logic has moved.

Other adjustments and improvements can be continue to be done in the other open issues.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Sun Jan 26 03:12:12 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jan 2020 08:12:12 +0000
Subject: [issue39456] Make IDLE calltip tests work when there are no docstrings
Message-ID: <1580026332.03.0.0808003249294.issue39456@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

IDLE should run and calltips and tests should work even callables lack docstrings, either because none is defined or because there are suppressed (CPython compile switch for builtins, CPython runtime switch for user objects).  I believe calltips work with or without docstrings present, but:

One User class test is skipped with -OO.  It should be changed to still work.

Multiple builtin tests fail.  #37501 proposes to skip them when compiled without docstrings.  The right long-term solution for IDLE is to change the tests.  My idea is to expand tiptest with 'out' replaced by the signature part, the processed docstring part, and the docstring object.  I want to try something like 

def tiptest(obj, docobj, sig, doc):
    out = sig += doc if docobj.__doc__ is not None else ''
    self.assertEqual(get_spec(obj), out)

----------
assignee: terry.reedy
components: IDLE
messages: 360722
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Make IDLE calltip tests work when there are no docstrings
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39456>
_______________________________________

From report at bugs.python.org  Sun Jan 26 03:18:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jan 2020 08:18:53 +0000
Subject: [issue39456] Make IDLE calltip tests work when there are no docstrings
In-Reply-To: <1580026332.03.0.0808003249294.issue39456@roundup.psfhosted.org>
Message-ID: <1580026733.69.0.458797267205.issue39456@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In a comment on PR-14592, I noted that other tests fail with -OO; these should be fixed (or skipped?) also.  test_calltips was the only failure with the compile switch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39456>
_______________________________________

From report at bugs.python.org  Sun Jan 26 03:26:17 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 26 Jan 2020 08:26:17 +0000
Subject: [issue39456] Make IDLE calltip tests work when there are no docstrings
In-Reply-To: <1580026332.03.0.0808003249294.issue39456@roundup.psfhosted.org>
Message-ID: <1580027177.61.0.582124975929.issue39456@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If test_calltips is fixed before PR-14592 is merged, it should be removed from the latter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39456>
_______________________________________

From report at bugs.python.org  Sun Jan 26 04:01:20 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Sun, 26 Jan 2020 09:01:20 +0000
Subject: [issue32309] Implement asyncio.run_in_executor shortcut
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1580029280.59.0.895121797291.issue32309@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> So, I just had an interesting idea... what if ThreadPool.run() returned a Task instead of a coroutine object?

After having some time to think this over, I prefer the current behavior. I don't think there would be significant enough improvement from returning a Task instead, and it would likely result in an overall performance loss.

Also, as a general update on the project, I'm close to being ready to open a PR to implement asyncio.ThreadPool. I finished the basic implementation and added a decent number of new tests to ensure its functionality. Here's my current progress: https://github.com/python/cpython/compare/master...aeros:asyncio-threadpool

I just need to work on adding the new documentation, and more specifically finding a good place for it in the current asyncio docs. Do you have any ideas for that, Yury? I figured that you might already have a preference in mind.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Sun Jan 26 04:07:41 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jan 2020 09:07:41 +0000
Subject: [issue39418] str.strip() should have a means of adding to the default
 behaviour
In-Reply-To: <1579695416.2.0.0994259543651.issue39418@roundup.psfhosted.org>
Message-ID: <1580029661.79.0.253184113792.issue39418@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

For this problem, I would reach for regular expressions.  They are specifically designed for flexibility and customization.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39418>
_______________________________________

From report at bugs.python.org  Sun Jan 26 10:30:33 2020
From: report at bugs.python.org (Chris Withers)
Date: Sun, 26 Jan 2020 15:30:33 +0000
Subject: [issue39082] AsyncMock is unable to correctly patch static or class
 methods
In-Reply-To: <1576629405.73.0.979234563097.issue39082@roundup.psfhosted.org>
Message-ID: <1580052633.52.0.26272322133.issue39082@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 19be85c76503535c101b38194d282187de0ff631 by Chris Withers (Matthew Kokotovich) in branch '3.8':
[3.8] bpo-39082: Allow AsyncMock to correctly patch static/class methods (GH-18190)
https://github.com/python/cpython/commit/19be85c76503535c101b38194d282187de0ff631


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39082>
_______________________________________

From report at bugs.python.org  Sun Jan 26 12:01:13 2020
From: report at bugs.python.org (Ernest W. Durbin III)
Date: Sun, 26 Jan 2020 17:01:13 +0000
Subject: [issue39309] Please delete my account
In-Reply-To: <1579351769.04.0.498329028577.issue39309@roundup.psfhosted.org>
Message-ID: <1580058073.7.0.89515792756.issue39309@roundup.psfhosted.org>


Ernest W. Durbin III <ernest at python.org> added the comment:

The account has been marked as "retired".

>From roundup docs:

  Items in the database are never deleted, they?re just ?retired?. You can still refer to them by ID - hence removing an item won?t break references to the item. It?s just that the item won?t appear in any listings.

I'm not sure what further action can be taken.

----------
nosy:  -sfjwlejfawnf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39309>
_______________________________________

From report at bugs.python.org  Sun Jan 26 12:03:40 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 26 Jan 2020 17:03:40 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1580058220.57.0.467917144671.issue10740@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

@Aymeric Augustin

> While you're there, it would be cool to provide "connection.autocommit = True" as an API to enable autocommit, because "connection.isolation_level = None" isn't a good API at all -- it's very obscure and has nothing to do with isolation level whatsoever.

+1. We could use this new autocommit property to enable the new full transactional mode (that is to say with transactional DDL):

```
connection.autocommit = True  # enable the autocommit mode
connection.autocommit = False  # disable the autocommit mode (enable the full transactional mode)
connection.autocommit = None  # fallback to connection.isolation_level
```

To transition from the old partial transactional mode (without transactional DDL) by default to the new full transactional mode (with transactional DDL) by default, we could use the following migration strategy:

1. During the deprecation period:

- Add the new autocommit property with the value None by default, so that the old partial transactional mode is still the default.
- Add a deprecation warning for the value None of the autocommit property, in favor of the other values True and False. It will prompt users who enabled the autocommit mode with connection.isolation_level = None to use connection.autocommit = True instead, and users who disabled the autocommit mode (that is to say users who enabled the old partial transactional mode) with connection.isolation_level = DEFERRED/IMMEDIATE/EXCLUSIVE to use connection.autocommit = False instead AND add to their code the potentially missing connection.commit() calls required by the new full transactional mode for committing DDL statements.

2. After the deprecation period:

- Set the value of the autocommit property to False by default, so that the new full transactional mode becomes the new default.
- Remove the value None of the autocommit property and its deprecation warning.
- Remove the value None of the isolation_level property, so that the old partial transactional mode disappears.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Sun Jan 26 12:26:33 2020
From: report at bugs.python.org (Dan Gass)
Date: Sun, 26 Jan 2020 17:26:33 +0000
Subject: [issue39451] enum.Enum reference count leaks
In-Reply-To: <1579933833.85.0.945475764886.issue39451@roundup.psfhosted.org>
Message-ID: <1580059593.27.0.745364531182.issue39451@roundup.psfhosted.org>


Dan Gass <dan.gass at gmail.com> added the comment:

Sorry for not thinking of trying this sooner. Running garbage collection, import gc; gc.collect(), releases the resources and restores the expected reference counts.

>From my perspective, this is satisfactory and could justify closing this bug report. 

The exception logic in Enum.__new__ could potentially be cleaned up for this use case, just not sure if that would introduce risk for other use cases. 

I am guessing (from the perspective of the larger Python exception handling design and implementation) what this bug report demonstrates had been previously thought through.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39451>
_______________________________________

From report at bugs.python.org  Sun Jan 26 13:05:39 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 26 Jan 2020 18:05:39 +0000
Subject: [issue39309] Please delete my account
In-Reply-To: <1579351769.04.0.498329028577.issue39309@roundup.psfhosted.org>
Message-ID: <1580061939.38.0.718009910862.issue39309@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39309>
_______________________________________

From report at bugs.python.org  Sun Jan 26 13:33:16 2020
From: report at bugs.python.org (Chris Aporta)
Date: Sun, 26 Jan 2020 18:33:16 +0000
Subject: [issue38971] codecs.open leaks file descriptor when invalid encoding
 is passed
In-Reply-To: <1575478307.61.0.215522324906.issue38971@roundup.psfhosted.org>
Message-ID: <1580063596.41.0.683543884344.issue38971@roundup.psfhosted.org>


Chris Aporta <christopher.aporta at gmail.com> added the comment:

Just quickly pinging the thread as a friendly reminder that PR 17666 is open and potentially close to mergeable, as it's been through two review cycles already (thanks Serhiy). If someone has the bandwidth to take another look, it would be greatly appreciated. Thanks!

----------
nosy: +caporta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38971>
_______________________________________

From report at bugs.python.org  Sun Jan 26 14:17:09 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 26 Jan 2020 19:17:09 +0000
Subject: [issue39457] Add an autocommit property to sqlite3.Connection with
 truly PEP 249 compliant manual commit mode and migrate
Message-ID: <1580066229.26.0.0229158792904.issue39457@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

In non-autocommit mode (manual commit mode), the sqlite3 database driver implicitly issues a BEGIN statement before each DML statement (INSERT, UPDATE, DELETE, REPLACE) not already in a database transaction, BUT NOT before DDL statements (CREATE, DROP) nor before DQL statements (SELECT) (cf. https://github.com/python/cpython/blob/master/Modules/_sqlite/cursor.c#L480):

```
    /* We start a transaction implicitly before a DML statement.
       SELECT is the only exception. See #9924. */
    if (self->connection->begin_statement && self->statement->is_dml) {
        if (sqlite3_get_autocommit(self->connection->db)) {
            result = _pysqlite_connection_begin(self->connection);
            if (!result) {
                goto error;
            }
            Py_DECREF(result);
        }
    }
```

Like Mike Bayer explained in issue #9924, this is not what other database drivers do, and this is not PEP 249 compliant (Python Database API Specification v2.0), as its author Marc-Andr? Lemburg explained (cf. https://mail.python.org/pipermail/db-sig/2010-September/005645.html):

> Randall Nortman wrote:
> # PEP 249 says that transactions end on commit() or rollback(), but it
> # doesn't explicitly state when transactions should begin, and there is
> # no begin() method. 
>
> Transactions start implicitly after you connect and after you call
.commit() or .rollback(). They are not started for each statement.
>
> # I think the implication is that transactions begin
> # on the first execute(), but that's not explicitly stated.  At least
> # one driver, pysqlite2/sqlite3, does not start a transaction for a
> # SELECT statement.  It waits for a DML statement (INSERT, UPDATE,
> # DELETE) before opening a transaction.  Other drivers open transactions
> # on any statement, including SELECT.
> #
> # My question for the DB-SIG is: Can I call it a bug in pysqlite2 that
> # it does not open transactions on SELECT?  Should the spec be amended
> # to make this explicit?  Or are both behaviors acceptable, in which
> # case perhaps a begin() method needs to be added for when the user
> # wants control over opening transactions?
>
> I should probably add a note to PEP 249 about this.

Aymeric Augustin said in issue #10740:

> While you're there, it would be cool to provide "connection.autocommit = True" as an API to enable autocommit, because "connection.isolation_level = None" isn't a good API at all -- it's very obscure and has nothing to do with isolation level whatsoever.

So I suggest that we introduce a new autocommit property and use it to enable a truly PEP 249 compliant manual commit mode (that is to say with transactions starting implicitly after connect(), commit() and rollback() calls, allowing transactional DDL and DQL):

```
autocommit = True  # enable the autocommit mode
autocommit = False  # disable the autocommit mode (enable the new PEP 249 manual commit mode)
autocommit = None  # fallback to the commit mode set by isolation_level
```

I also suggest that we use this new PEP 249 manual commit mode (with transactional DDL and DQL) by default and drop the old manual commit mode (without transactional DDL and DQL). We could use the following migration strategy:

1. During the deprecation period:

- Add the new autocommit property with the value None by default, so that the old manual commit mode is still the default.
- Add a deprecation warning for the value None of the autocommit property, in favor of the other values True and False. It will prompt users who enabled the autocommit mode with isolation_level = None to use autocommit = True instead, and users who disabled the autocommit mode (that is to say users who enabled the old manual commit mode) with isolation_level = DEFERRED/IMMEDIATE/EXCLUSIVE to use autocommit = False instead AND add to their code the potentially missing commit() calls required by the new PEP 249 manual commit mode.

2. After the deprecation period:

- Set the value of the autocommit property to False by default, so that the new PEP 249 manual commit mode becomes the new default.
- Remove the value None of the autocommit property and its deprecation warning.
- Remove the value None of the isolation_level property, so that the old manual commit mode disappears.

----------
components: Library (Lib)
messages: 360732
nosy: ghaering, lemburg, maggyero, r.david.murray, zzzeek
priority: normal
severity: normal
status: open
title: Add an autocommit property to sqlite3.Connection with truly PEP 249 compliant manual commit mode and migrate
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39457>
_______________________________________

From report at bugs.python.org  Sun Jan 26 14:24:54 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 26 Jan 2020 19:24:54 +0000
Subject: [issue39457] Add an autocommit property to sqlite3.Connection with a
 PEP 249 compliant manual commit mode and migrate
In-Reply-To: <1580066229.26.0.0229158792904.issue39457@roundup.psfhosted.org>
Message-ID: <1580066694.1.0.594012275311.issue39457@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
title: Add an autocommit property to sqlite3.Connection with truly PEP 249 compliant manual commit mode and migrate -> Add an autocommit property to sqlite3.Connection with a PEP 249 compliant manual commit mode and migrate

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39457>
_______________________________________

From report at bugs.python.org  Sun Jan 26 14:27:00 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 26 Jan 2020 19:27:00 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1580066820.41.0.304448133319.issue10740@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

@R. David Murray

> Please open a new issue for this request.

Done here: https://bugs.python.org/issue39457

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Sun Jan 26 14:33:18 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 26 Jan 2020 19:33:18 +0000
Subject: [issue39457] Add an autocommit property to sqlite3.Connection with a
 PEP 249 compliant manual commit mode and migrate
In-Reply-To: <1580066229.26.0.0229158792904.issue39457@roundup.psfhosted.org>
Message-ID: <1580067198.22.0.103449027497.issue39457@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

> - Remove the value None of the isolation_level property, so that the old manual commit mode disappears.

Correction:

- Remove the value None of the isolation_level property.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39457>
_______________________________________

From report at bugs.python.org  Sun Jan 26 14:41:20 2020
From: report at bugs.python.org (SilentGhost)
Date: Sun, 26 Jan 2020 19:41:20 +0000
Subject: [issue39457] Add an autocommit property to sqlite3.Connection with a
 PEP 249 compliant manual commit mode and migrate
In-Reply-To: <1580066229.26.0.0229158792904.issue39457@roundup.psfhosted.org>
Message-ID: <1580067680.62.0.766942731491.issue39457@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39457>
_______________________________________

From report at bugs.python.org  Sun Jan 26 17:07:24 2020
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 26 Jan 2020 22:07:24 +0000
Subject: [issue39457] Add an autocommit property to sqlite3.Connection with a
 PEP 249 compliant manual commit mode and migrate
In-Reply-To: <1580066229.26.0.0229158792904.issue39457@roundup.psfhosted.org>
Message-ID: <1580076444.89.0.591503187106.issue39457@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

> - Remove the value None of the autocommit property and its deprecation warning.

Correction:

- Remove the value None of the autocommit property and its deprecation warning, so that the old manual commit mode disappears.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39457>
_______________________________________

From report at bugs.python.org  Sun Jan 26 17:30:15 2020
From: report at bugs.python.org (Gabriel Tardif)
Date: Sun, 26 Jan 2020 22:30:15 +0000
Subject: [issue39458] Multiprocessing.Pool maxtasksperchild=1 doesn't work
Message-ID: <1580077815.77.0.653421680761.issue39458@roundup.psfhosted.org>


New submission from Gabriel Tardif <gabriel at zeroinfo.tech>:

Hello

This bug is about the maxtasksperchild parameter in the Pool object constructor of the multiprocessing module.

When you set processes = 1 in the Pool constructor
maxtasksperchild value is double by two for unknow raison whatever the maxtaskperchild value.

As mentionned in the documentation, once the process has reach the maxtasksperchil value it should rebuild itself in the memory from the parent process.

In the short python exemple provided below, you can see the value of showedFiles of each process incresing over 1 which is not normal if Pool constructor is set to processes = 1, maxtasksperchil = 1.

The only running process should destroy / reset itself and so set its value 'showedFiles' to 0 first and 1 for each os.listdir() entry.

----------
assignee: docs at python
components: Documentation
files: reader.py
messages: 360736
nosy: Gabriel Tardif, docs at python
priority: normal
severity: normal
status: open
title: Multiprocessing.Pool maxtasksperchild=1 doesn't work
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48864/reader.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39458>
_______________________________________

From report at bugs.python.org  Sun Jan 26 18:49:35 2020
From: report at bugs.python.org (Emmanuel Arias)
Date: Sun, 26 Jan 2020 23:49:35 +0000
Subject: [issue38599] Deprecate creation of asyncio object when the loop is
 not running
In-Reply-To: <1572160085.79.0.39835517746.issue38599@roundup.psfhosted.org>
Message-ID: <1580082575.58.0.67332379441.issue38599@roundup.psfhosted.org>


Change by Emmanuel Arias <eamanu at yaerobi.com>:


----------
pull_requests: +17576
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18195

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38599>
_______________________________________

From report at bugs.python.org  Sun Jan 26 18:51:39 2020
From: report at bugs.python.org (chris)
Date: Sun, 26 Jan 2020 23:51:39 +0000
Subject: [issue37625] Class variable is still accessible after class instance
 has been overwritten out
In-Reply-To: <1563486914.84.0.86753245558.issue37625@roundup.psfhosted.org>
Message-ID: <1580082699.99.0.162353662622.issue37625@roundup.psfhosted.org>


chris <logingitsite at gmail.com> added the comment:

Great content and outstanding, How can I start getting your <a href="https://logingit.com/www-txsurchargeonline-com-login-tx-surcharge-pay/">newsletters</a> in my email to enable keep track of your future content? Thank for this great piece.

----------
nosy: +Nadas

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37625>
_______________________________________

From report at bugs.python.org  Sun Jan 26 21:56:17 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jan 2020 02:56:17 +0000
Subject: [issue37625] Class variable is still accessible after class instance
 has been overwritten out
In-Reply-To: <1563486914.84.0.86753245558.issue37625@roundup.psfhosted.org>
Message-ID: <1580093777.19.0.844051632957.issue37625@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg360737

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37625>
_______________________________________

From report at bugs.python.org  Mon Jan 27 00:39:03 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 27 Jan 2020 05:39:03 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
In-Reply-To: <1579776260.84.0.333075912412.issue39380@roundup.psfhosted.org>
Message-ID: <1580103543.74.0.648474757883.issue39380@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I'm not FTP user so I don't have strong opinion.
If it is too late to change already, change it in 3.9 might be OK.

> However, shouldn't it be a FutureWarning, so it will be reported by default at initialisation?

If it is warning for end users, it should be FutureWarning.
If the warning is for developers, it should be DeprecationWarning.
Warning for API changes is DeprecationWarning in general.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Mon Jan 27 01:48:29 2020
From: report at bugs.python.org (Chris Withers)
Date: Mon, 27 Jan 2020 06:48:29 +0000
Subject: [issue25597] unittest.mock does not wrap dunder methods (__getitem__
 etc)
In-Reply-To: <1447174958.96.0.448093662654.issue25597@psf.upfronthosting.co.za>
Message-ID: <1580107709.4.0.380964759933.issue25597@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 72b1004657e60c900e4cd031b2635b587f4b280e by Chris Withers (Karthikeyan Singaravelan) in branch 'master':
bpo-25597: Ensure wraps' return value is used for magic methods in MagicMock (#16029)
https://github.com/python/cpython/commit/72b1004657e60c900e4cd031b2635b587f4b280e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25597>
_______________________________________

From report at bugs.python.org  Mon Jan 27 02:59:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 07:59:03 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
In-Reply-To: <1579776260.84.0.333075912412.issue39380@roundup.psfhosted.org>
Message-ID: <1580111943.97.0.376202711348.issue39380@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm in favor of changing the default encoding to UTF-8, but it requires good documentation, especially to provide a solution working on Python 3.8 and 3.9 to change the encoding (see below).

--

The encoding is used to encode commands with the FTP server and decode the server replies. I expect that most replies are basically letters, digits and spaces. I guess that the most problematic commands are:

* send user and password
* decode filenames of LIST command reply
* encode filename in STOR command

I expect that the original FTP protocol doesn't specify any encoding and so that FTP server implementations took some freedom. I would not be surprised to use ANSI code pages used on servers running on Windows.

Currently, encoding is a class attribute: it's not convenient to override it depending on the host. I would prefer to have a new parameter for the constructor.

Giampaolo:
> some servers may enable UTF-8 only if client explicitly sends "OPTS UTF-8 ON" first, but that is based on an draft RFC. Server implementors usually treat this command as a no-op and simply assume UTF-8 as the default.
> With that said, I am -1 about implementing logic based on FEAT/OPTS: that should be done before login, and at that point some servers may erroneously reject any command other than USER, PASS and ACCT. 

Oh. In this case, always send "OPTS UTF-8 ON" just after the socket is connected sounds like a bad idea.


Sebastian:
> Since RFC 2640, the industry standard within FTP Clients is UTF-8 (see e.g. FileZilla here: https://wiki.filezilla-project.org/Character_Encoding, or WinSCP here: https://winscp.net/eng/docs/faq_utf8).

"Internationalization of the File Transfer Protocol" was published in 1999. It recommends the UTF-8. Following a RFC recommendation is good argument to change the default encoding to UTF-8.
https://tools.ietf.org/html/rfc2640


Giampaolo:
> Personally I think it makes more sense to just use UTF-8 without going through a deprecation period

I concur. Deprecation is usually used for features which are going to be removed (module, function or function parameter). Here it's just about a default parameter value. I expect to have encoding="utf-8" default in the constructor.

The annoying part is that Python 3.8 only has a class attribute. The simplest option seems to be creating a FTP object, modify its encoding attribute and *then* logs in. Another options is to subclass the FTP class. IMO the worst is to modify ftplib.FTP.encoding attribute (monkey patch the module).

I expect that most users use username, password and filenames encodable to ASCII and so will not notify the change to UTF-8. We can document a solution working on all Python versions to use different encoding name.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Mon Jan 27 03:01:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 08:01:02 +0000
Subject: [issue39380] ftplib uses latin-1 as default encoding
In-Reply-To: <1579776260.84.0.333075912412.issue39380@roundup.psfhosted.org>
Message-ID: <1580112062.55.0.564683584599.issue39380@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Before changing the default, I would prefer to see a PR adding an encoding parameter to the FTP constructor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39380>
_______________________________________

From report at bugs.python.org  Mon Jan 27 03:22:16 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 27 Jan 2020 08:22:16 +0000
Subject: [issue38856] asyncio ProactorEventLoop: wait_closed() can raise
 ConnectionResetError
In-Reply-To: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>
Message-ID: <1580113336.64.0.44225711945.issue38856@roundup.psfhosted.org>


Kyle Stanley <aeros167 at gmail.com> added the comment:

> The exception should probably be just ignored.

It looks like the "ERROR_NETNAME_DELETED" (win32 error 64) exception is already ignored in multiprocessing's connection.wait(): https://github.com/python/cpython/blob/bccacd19fa7b56dcf2fbfab15992b6b94ab6666b/Lib/multiprocessing/connection.py#L857. Would it be appropriate to ignore it here as well?

I think that we should still retain the ConnectionResetError for "ERROR_OPERATION_ABORTED", but just specifically ignore "ERROR_NETNAME_DELETED". Ignoring "ERROR_OPERATION_ABORTED" doesn't seem correct here since it's relied on for cancelling file I/O (see https://docs.microsoft.com/en-us/windows/win32/fileio/canceling-pending-i-o-operations).

The patch should be straightforward. I'll test it locally and then open a PR, unless Andrew is currently working on it.

----------
nosy: +aeros

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Mon Jan 27 03:40:14 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Mon, 27 Jan 2020 08:40:14 +0000
Subject: [issue38856] asyncio ProactorEventLoop: wait_closed() can raise
 ConnectionResetError
In-Reply-To: <1574201186.66.0.441437608856.issue38856@roundup.psfhosted.org>
Message-ID: <1580114414.73.0.00986067834695.issue38856@roundup.psfhosted.org>


Change by Kyle Stanley <aeros167 at gmail.com>:


----------
keywords: +patch
pull_requests: +17577
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18199

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38856>
_______________________________________

From report at bugs.python.org  Mon Jan 27 04:19:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 09:19:04 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
Message-ID: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

AMD64 Fedora Stable Clang Installed 3.x:
https://buildbot.python.org/all/#/builders/127/builds/212

test_unwritable_module (test.test_import.CircularImportTests) ... ERROR

======================================================================
ERROR: test_unwritable_module (test.test_import.CircularImportTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-stable-x86_64.clang-installed/build/target/lib/python3.9/test/test_import/__init__.py", line 1347, in test_unwritable_module
    import test.test_import.data.unwritable as unwritable
ModuleNotFoundError: No module named 'test.test_import.data.unwritable'

----------
components: Tests
messages: 360743
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_import: test_unwritable_module() fails on AMD64 Fedora Stable Clang Installed 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 04:19:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 09:19:25 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580116765.77.0.519533158852.issue39459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Test added in bpo-39336 by:

commit 9b6fec46513006d7b06fcb645cca6e4f5bf7c7b8
Author: Dino Viehland <dinoviehland at gmail.com>
Date:   Wed Jan 22 16:42:38 2020 -0800

    bpo-39336: Allow packages to not let their child modules be set on them (#18006)
    
    * bpo-39336: Allow setattr to fail on modules which aren't assignable
    
    When attaching a child module to a package if the object in sys.modules raises an Attribu
teError (e.g. because it is immutable) it causes the whole import to fail.  This now allows i
mmutable packages to exist and an ImportWarning is reported and the AttributeError exception 
is ignored.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 04:20:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 09:20:03 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1580116803.42.0.848031775748.issue39336@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_unwritable_module() fails on AMD64 Fedora Stable Clang Installed 3.x: bpo-39459.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Mon Jan 27 04:20:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 09:20:10 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580116810.19.0.466910544279.issue39459@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 04:20:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 09:20:50 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580116850.93.0.948592335081.issue39459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Same error on x86 Gentoo Installed with X 3.x:
https://buildbot.python.org/all/#/builders/128/builds/204

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 04:24:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 09:24:50 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
Message-ID: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

s390x Fedora Rawhide 3.x:
https://buildbot.python.org/all/#/builders/323/builds/6

======================================================================
FAIL: test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-fedora-rawhide-z/build/Lib/test/test_zipfile.py", line 620, in test_add_file_after_2107
    self.assertRaises(struct.error, zipfp.write, TESTFN)
AssertionError: error not raised by write

Test added in bpo-34097 by:

commit a2fe1e52eb94c41d9ebce1ab284180d7b1faa2a4
Author: Marcel Plch <gmarcel.plch at gmail.com>
Date:   Thu Aug 2 15:04:52 2018 +0200

    bpo-34097: Add support for zipping files older than 1980-01-01 (GH-8270)
    
    ZipFile can zip files older than 1980-01-01 and newer than 2107-12-31 using
    a new strict_timestamps parameter at the cost of setting the timestamp
    to the limit.

see also the following fix:

commit 7b41dbad78c6b03ca2f98800a92a1977d3946643
Author: Marcel Plch <gmarcel.plch at gmail.com>
Date:   Fri Aug 3 17:59:19 2018 +0200

    bpo-34325: Skip zipfile test for large timestamps when filesystem don't support them. (GH-8656)
    
    When the filesystem doesn't support files with large timestamps,
    skip testing that such files can be zipped.

----------
components: Tests
messages: 360747
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_zipfile: test_add_file_after_2107() fails on s390x Fedora Rawhide 3.x
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Mon Jan 27 04:25:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 09:25:05 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580117105.04.0.157775453609.issue39460@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +Dormouse759

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Mon Jan 27 04:34:14 2020
From: report at bugs.python.org (Jonas Drotleff)
Date: Mon, 27 Jan 2020 09:34:14 +0000
Subject: [issue38337] inspect: getmembers calls properties
In-Reply-To: <1569931319.11.0.161787180553.issue38337@roundup.psfhosted.org>
Message-ID: <1580117654.2.0.377894509754.issue38337@roundup.psfhosted.org>


Jonas Drotleff <jonas.drotleff at gmail.com> added the comment:

> Here is a link to the discussion of this on ideas

Thank you for posting the link.

I feel like I came to a dead end with this issue. As I am fairly new to CPython and have never contributed to this project before, I have no idea how to address this and to whom. Maybe this is just to irrelevant and not important, but even then we should probably close this issue or mark it as "indefinitely postponed" or something similar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38337>
_______________________________________

From report at bugs.python.org  Mon Jan 27 04:57:49 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 27 Jan 2020 09:57:49 +0000
Subject: [issue39320] Handle unpacking of */** arguments and rvalues in the
 compiler
In-Reply-To: <1578918490.54.0.342025462897.issue39320@roundup.psfhosted.org>
Message-ID: <1580119069.6.0.393931897293.issue39320@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 8a4cd700a7426341c2074a2b580306d2d60ec839 by Mark Shannon in branch 'master':
bpo-39320: Handle unpacking of **values in compiler (GH-18141)
https://github.com/python/cpython/commit/8a4cd700a7426341c2074a2b580306d2d60ec839


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39320>
_______________________________________

From report at bugs.python.org  Mon Jan 27 05:25:58 2020
From: report at bugs.python.org (Antony Lee)
Date: Mon, 27 Jan 2020 10:25:58 +0000
Subject: [issue39461] os.environ does not support Path-like values,
 but subprocess(..., env=...) does
Message-ID: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

As of Py3.8/Linux:

    In [1]: os.environ["foo"] = Path("bar")                                                                             
    ---------------------------------------------------------------------------
    TypeError                                 Traceback (most recent call last)
    <ipython-input-4-2827297496cb> in <module>
    ----> 1 os.environ["foo"] = Path("bar")

    ~/miniconda3/envs/default/lib/python3.8/os.py in __setitem__(self, key, value)
        676     def __setitem__(self, key, value):
        677         key = self.encodekey(key)
    --> 678         value = self.encodevalue(value)
        679         self.putenv(key, value)
        680         self._data[key] = value

    ~/miniconda3/envs/default/lib/python3.8/os.py in encode(value)
        746         def encode(value):
        747             if not isinstance(value, str):
    --> 748                 raise TypeError("str expected, not %s" % type(value).__name__)
        749             return value.encode(encoding, 'surrogateescape')
        750         def decode(value):

    TypeError: str expected, not PosixPath

    In [2]: subprocess.run('echo "$foo"', env={**os.environ, "foo": Path("bar")}, shell=True)                           
    bar
    Out[2]: CompletedProcess(args='echo "$foo"', returncode=0)

I guess it would be nice if it was possible to set os.environ entries to Path-like values, but most importantly, it seems a bit inconsistent that doing so is not possible on os.environ, but works when setting the `env` of a subprocess call.

----------
components: Library (Lib)
messages: 360750
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: os.environ does not support Path-like values, but subprocess(..., env=...) does
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 05:51:13 2020
From: report at bugs.python.org (Peter Liedholm)
Date: Mon, 27 Jan 2020 10:51:13 +0000
Subject: [issue39340] shutil.rmtree and write protected files
In-Reply-To: <1579080933.31.0.376881618975.issue39340@roundup.psfhosted.org>
Message-ID: <1580122273.76.0.071431322144.issue39340@roundup.psfhosted.org>


Peter Liedholm <peterfromswe884 at gmail.com> added the comment:

What I would expect is a consistent behaviour and as a user I am not interested in inner guts of differences between filesystems.
Regards
/Peter

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39340>
_______________________________________

From report at bugs.python.org  Mon Jan 27 06:09:27 2020
From: report at bugs.python.org (Marcel)
Date: Mon, 27 Jan 2020 11:09:27 +0000
Subject: [issue39462] DataClass typo-unsafe attribute creation & unexpected
 behaviour (dataclasses)
Message-ID: <1580123367.77.0.985368571212.issue39462@roundup.psfhosted.org>


New submission from Marcel <mpv.visser at gmail.com>:

After instantiation of a variable of a DataClass, it is possible to assign new attributes (that were not defined in defining the DataClass):

data.new_attribute = 3.0  # does NOT raise Error!

This gives unexpected behaviour: if you print the variable, then 'new_attribute' is not printed (since it is not in the definition of the DataClass).

Assigning to an attribute is therefore not typo-safe (which users may expect from a DataClass).

I would expect the behaviour of the DataClass be consistent and typo-safe.

Attached is a file that demonstrates the bug (behaviour) and provides a 'SafeDataClass' by overriding the __setattr__ method.

My suggestion would be to the adjust the library __setattr__ for the DataClass such that is will be typo-safe.

----------
components: Library (Lib)
files: bug_demo_dataclass_typo_unsafe.py
messages: 360752
nosy: marcelpvisser
priority: normal
severity: normal
status: open
title: DataClass typo-unsafe attribute creation & unexpected behaviour (dataclasses)
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48865/bug_demo_dataclass_typo_unsafe.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39462>
_______________________________________

From report at bugs.python.org  Mon Jan 27 06:18:53 2020
From: report at bugs.python.org (Marcel)
Date: Mon, 27 Jan 2020 11:18:53 +0000
Subject: [issue39462] DataClass typo-unsafe attribute creation & unexpected
 behaviour (dataclasses)
In-Reply-To: <1580123367.77.0.985368571212.issue39462@roundup.psfhosted.org>
Message-ID: <1580123933.4.0.307183870009.issue39462@roundup.psfhosted.org>


Marcel <mpv.visser at gmail.com> added the comment:

The demo-script also needs:

"from dataclasses import dataclass"

Sorry about this omission, I've attached the update

----------
Added file: https://bugs.python.org/file48866/bug_demo_dataclass_typo_unsafe.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39462>
_______________________________________

From report at bugs.python.org  Mon Jan 27 06:40:03 2020
From: report at bugs.python.org (Tal Ben-Nun)
Date: Mon, 27 Jan 2020 11:40:03 +0000
Subject: [issue39463] ast.Constant, bytes, and ast.unparse
Message-ID: <1580125203.43.0.757991294489.issue39463@roundup.psfhosted.org>


New submission from Tal Ben-Nun <tbennun at gmail.com>:

In Python 3.8, the "kind" field was introduced into the Constant AST class. This brings about a problem when unparsing the AST for various packages. First, it breaks backward compatibility for older code that creates ast.Num without specifying kind (which is optional anyway and does not exist in its fields). Second, since bytes are parsed as a Constant without a kind, one can create the following (valid as of now) AST and unparse it:

ast.unparse(ast.Constant(value=b"bad", kind="u"))

Getting "ub'bad'", which is invalid Python syntax AFAIU.

Could something be done with the classes that extend ast.Constant and with bytes being a Constant with a "kind" of "b"?

----------
components: Library (Lib)
messages: 360754
nosy: Tal Ben-Nun
priority: normal
severity: normal
status: open
title: ast.Constant, bytes, and ast.unparse
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39463>
_______________________________________

From report at bugs.python.org  Mon Jan 27 06:40:58 2020
From: report at bugs.python.org (Tal Ben-Nun)
Date: Mon, 27 Jan 2020 11:40:58 +0000
Subject: [issue39463] ast.Constant, bytes, and ast.unparse
In-Reply-To: <1580125203.43.0.757991294489.issue39463@roundup.psfhosted.org>
Message-ID: <1580125258.17.0.841791062628.issue39463@roundup.psfhosted.org>


Change by Tal Ben-Nun <tbennun at gmail.com>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39463>
_______________________________________

From report at bugs.python.org  Mon Jan 27 06:58:17 2020
From: report at bugs.python.org (Batuhan)
Date: Mon, 27 Jan 2020 11:58:17 +0000
Subject: [issue39463] ast.Constant, bytes, and ast.unparse
In-Reply-To: <1580125203.43.0.757991294489.issue39463@roundup.psfhosted.org>
Message-ID: <1580126297.84.0.703234069845.issue39463@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

Origin of this thread: https://github.com/simonpercivall/astunparse/pull/44

----------
nosy: +BTaskaya, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39463>
_______________________________________

From report at bugs.python.org  Mon Jan 27 07:26:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 12:26:04 +0000
Subject: [issue39461] os.environ does not support Path-like values,
 but subprocess(..., env=...) does
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580127964.55.0.0650644669465.issue39461@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

subprocess.Popen encodes the env parameter using os.fsencode(). os.fsencode() has been patched in bpo-27182 to use os.fspath():

commit c1cbeedf0c650c3f7c64f04479070d39e15e1baf
Author: Ethan Furman <ethan at stoneleaf.us>
Date:   Sat Jun 4 10:19:27 2016 -0700

    issue27182: update fsencode and fsdecode for os.path(); patch by Dusty Phillips

For os.environ, you can use:

    os.environ["foo"] = str(Path("bar"))

I don't know if os.environ is supposed to use the fspath protocol. I add Ethan and Brett to the nosy list.

fspath is specified by the PEP 519 "Adding a file system path protocol":
https://www.python.org/dev/peps/pep-0519/

----------
nosy: +brett.cannon, ethan.furman, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 07:26:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 12:26:30 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580127990.45.0.617205609966.issue39461@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: os.environ does not support Path-like values, but subprocess(..., env=...) does -> [RFE] os.environ should support Path-like values, like subprocess(..., env=...)
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 07:28:06 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Jan 2020 12:28:06 +0000
Subject: [issue39463] ast.Constant, bytes, and ast.unparse
In-Reply-To: <1580125203.43.0.757991294489.issue39463@roundup.psfhosted.org>
Message-ID: <1580128086.26.0.973919899923.issue39463@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> First, it breaks backward compatibility for older code that creates ast.Num without specifying kind 

The ast changes during versions, and in the current master there are no "Num" nodes, so not much we could do there safely.

>Second, since bytes are parsed as a Constant without a kind, one can create the following (valid as of now) AST and unparse it:

You can create multiple malformed ast objects that will crash the interpreter if you pass it to `compile` or other functions that expect a valid AST. Passing invalid AST objects to these functions is out of contract (also, sanitizing that an AST is valid will make this functions much slower and will be a lot of code to maintain and CPython itself will not benefit much from it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39463>
_______________________________________

From report at bugs.python.org  Mon Jan 27 07:28:26 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Jan 2020 12:28:26 +0000
Subject: [issue39463] ast.Constant, bytes, and ast.unparse
In-Reply-To: <1580125203.43.0.757991294489.issue39463@roundup.psfhosted.org>
Message-ID: <1580128106.16.0.12443429451.issue39463@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> First, it breaks backward compatibility for older code that creates ast.Num without specifying kind 

The ast changes during versions, and in the current master there are no "Num" nodes, so not much we could do there sadly.

>Second, since bytes are parsed as a Constant without a kind, one can create the following (valid as of now) AST and unparse it:

You can create multiple malformed ast objects that will crash the interpreter if you pass it to `compile` or other functions that expect a valid AST. Passing invalid AST objects to these functions is out of contract (also, sanitizing that an AST is valid will make this functions much slower and will be a lot of code to maintain and CPython itself will not benefit much from it).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39463>
_______________________________________

From report at bugs.python.org  Mon Jan 27 07:28:30 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Jan 2020 12:28:30 +0000
Subject: [issue39463] ast.Constant, bytes, and ast.unparse
In-Reply-To: <1580125203.43.0.757991294489.issue39463@roundup.psfhosted.org>
Message-ID: <1580128110.87.0.121424547125.issue39463@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg360757

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39463>
_______________________________________

From report at bugs.python.org  Mon Jan 27 07:31:04 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Jan 2020 12:31:04 +0000
Subject: [issue39463] ast.Constant, bytes, and ast.unparse
In-Reply-To: <1580125203.43.0.757991294489.issue39463@roundup.psfhosted.org>
Message-ID: <1580128264.12.0.479124066856.issue39463@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Maybe we need to clarify to the docs of 'unparse' that the AST object needs to be valid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39463>
_______________________________________

From report at bugs.python.org  Mon Jan 27 07:31:28 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jan 2020 12:31:28 +0000
Subject: [issue39462] DataClass typo-unsafe attribute creation & unexpected
 behaviour (dataclasses)
In-Reply-To: <1580123367.77.0.985368571212.issue39462@roundup.psfhosted.org>
Message-ID: <1580128288.72.0.370846803862.issue39462@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39462>
_______________________________________

From report at bugs.python.org  Mon Jan 27 07:46:43 2020
From: report at bugs.python.org (=?utf-8?q?Wojciech_=C5=81opata?=)
Date: Mon, 27 Jan 2020 12:46:43 +0000
Subject: [issue39442] from __future__ import annotations makes
 dataclasses.Field.type a string, not type
In-Reply-To: <1579866520.75.0.652812484582.issue39442@roundup.psfhosted.org>
Message-ID: <1580129203.78.0.533327392039.issue39442@roundup.psfhosted.org>


Wojciech ?opata <wlopata at gmail.com> added the comment:

I thought of this behaviour as a bug, because PEP 563 mentions breaking  "applications depending on arbitrary objects to be directly present in annotations", while it is also breaking users of dataclasses.fields(), that is a part of the standard library. But if it's not something worth fighting for, feel free to close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39442>
_______________________________________

From report at bugs.python.org  Mon Jan 27 08:11:56 2020
From: report at bugs.python.org (Alex Hall)
Date: Mon, 27 Jan 2020 13:11:56 +0000
Subject: [issue33997] multiprocessing Pool hangs in terminate()
In-Reply-To: <1530275873.32.0.56676864532.issue33997@psf.upfronthosting.co.za>
Message-ID: <1580130716.41.0.590254400118.issue33997@roundup.psfhosted.org>


Alex Hall <alex.mojaki at gmail.com> added the comment:

I'm also experiencing hanging on terminate. I haven't made a debug build or anything but it's happening to me consistently on 3.8, although I haven't managed to create a small example to reproduce. Replacing pool.py with https://raw.githubusercontent.com/python/cpython/5f6a05bf5b3f7e3c1d805b3bbd8c5ad18f26d933/Lib/multiprocessing/pool.py (from the PR) did not help. So maybe what I'm experiencing is unrelated.

It gets stuck on `inqueue._rlock.acquire()` in `Pool._help_stuff_finish`. I've attached debugging info from snoop, maybe that will help.

----------
nosy: +alexmojaki
Added file: https://bugs.python.org/file48867/pool_terminate_snoop.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33997>
_______________________________________

From report at bugs.python.org  Mon Jan 27 08:24:55 2020
From: report at bugs.python.org (Alex Hall)
Date: Mon, 27 Jan 2020 13:24:55 +0000
Subject: [issue33997] multiprocessing Pool hangs in terminate()
In-Reply-To: <1530275873.32.0.56676864532.issue33997@psf.upfronthosting.co.za>
Message-ID: <1580131495.23.0.664154497208.issue33997@roundup.psfhosted.org>


Alex Hall <alex.mojaki at gmail.com> added the comment:

Sorry, I should have looked around more, I think my problem is https://bugs.python.org/issue22393

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33997>
_______________________________________

From report at bugs.python.org  Mon Jan 27 08:47:55 2020
From: report at bugs.python.org (Batuhan)
Date: Mon, 27 Jan 2020 13:47:55 +0000
Subject: [issue39463] ast.Constant, bytes, and ast.unparse
In-Reply-To: <1580125203.43.0.757991294489.issue39463@roundup.psfhosted.org>
Message-ID: <1580132875.37.0.832799567253.issue39463@roundup.psfhosted.org>


Batuhan <batuhanosmantaskaya at gmail.com> added the comment:

> Maybe we need to clarify to the docs of 'unparse' that the AST object needs to be valid.

As I stated earlier, constant tuple like things are valid but don't fit on description. Maybe we should only offically allow things that can be generated by ast.parse? We can still implement support for constant tuples etc but we shouldnt have to check malformed ast.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39463>
_______________________________________

From report at bugs.python.org  Mon Jan 27 08:55:37 2020
From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Manuel_Ferrer?=)
Date: Mon, 27 Jan 2020 13:55:37 +0000
Subject: [issue39464] Allow translating argument error messages
Message-ID: <1580133337.82.0.00677207154431.issue39464@roundup.psfhosted.org>


New submission from Jos? Manuel Ferrer <jmfo1982 at gmail.com>:

Argument error messages display the untranslatable text 'argument ', which should be translatable to other languages, just like it's possible to do with the rest of the constructed error message.

----------
components: Library (Lib)
messages: 360764
nosy: DjMorgul
priority: normal
pull_requests: 17578
severity: normal
status: open
title: Allow translating argument error messages
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39464>
_______________________________________

From report at bugs.python.org  Mon Jan 27 09:20:26 2020
From: report at bugs.python.org (Patrick Buxton)
Date: Mon, 27 Jan 2020 14:20:26 +0000
Subject: [issue39104] ProcessPoolExecutor hangs on shutdown nowait with
 pickling failure
In-Reply-To: <1576824742.02.0.740148547005.issue39104@roundup.psfhosted.org>
Message-ID: <1580134826.26.0.315912175713.issue39104@roundup.psfhosted.org>


Change by Patrick Buxton <patrick.buxton at tartansolutions.com>:


----------
nosy: +bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39104>
_______________________________________

From report at bugs.python.org  Mon Jan 27 09:27:02 2020
From: report at bugs.python.org (chris)
Date: Mon, 27 Jan 2020 14:27:02 +0000
Subject: [issue37625] Class variable is still accessible after class instance
 has been overwritten out
In-Reply-To: <1563486914.84.0.86753245558.issue37625@roundup.psfhosted.org>
Message-ID: <1580135222.68.0.57257184646.issue37625@roundup.psfhosted.org>


chris <logingitsite at gmail.com> added the comment:

Great and I look forward to getting more content. Incredibly great.
https://logingit.com/dish-network-login/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37625>
_______________________________________

From report at bugs.python.org  Mon Jan 27 09:28:30 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 27 Jan 2020 14:28:30 +0000
Subject: [issue39465] Design a subinterpreter friendly alternative to
 _Py_IDENTIFIER
Message-ID: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Both https://github.com/python/cpython/pull/18066 (collections module) and https://github.com/python/cpython/pull/18032 (asyncio module) ran into the problem where porting them to multi-phase initialisation involves replacing their usage of the `_Py_IDENTIFIER` macro with some other mechanism.

When _posixsubprocess was ported, the replacement was a relatively ad hoc combination of string interning and the interpreter-managed module-specific state: https://github.com/python/cpython/commit/5a7d2e11aaea2dd32878dc5c6b1aae8caf56cb44

I'm wondering if we may able to devise a comparable struct-field based system that replaces the `_Py_IDENTIFIER` local static variable declaration macro and the `Py_Id_<name>` lookup convention with a combination like (using the posix subprocess module conversion as an example):

    // Identifier usage declaration (replaces _Py_IDENTIFIER)
    _Py_USE_CACHED_IDENTIFIER(_posixsubprocessstate(m), disable);

    // Identifier usage remains unchanged, but uses a regular local variable
    // rather than the static variable declared by _Py_IDENTIFIER
    result = _PyObject_CallMethodIdNoArgs(gc_module, &PyId_disable);

And then the following additional state management macros would be needed to handle the string interning and reference counting:

    // Module state struct declaration
    typedef struct {
        // This would declare an initialised array of _Py_Identifier structs
        // under a name like __cached_identifiers__. The end of the array
        // would be indicated by a strict with "value" set to NULL.
        _Py_START_CACHED_IDENTIFIERS;
        _Py_CACHED_IDENTIFIER(disable);
        _Py_CACHED_IDENTIFIER(enable);
        _Py_CACHED_IDENTIFIER(isenabled);
        _Py_END_CACHED_IDENTIFIERS;
        );
    } _posixsubprocessstate;

    // Module tp_traverse implementation
    _Py_VISIT_CACHED_IDENTIFIERS(_posixsubprocessstate(m));

    // Module tp_clear implementation (also called by tp_free)
    _Py_CLEAR_CACHED_IDENTIFIERS(_posixsubprocessstate(m));

With the requirement to declare usage of the cached identifiers, they could be lazily initialized the same way the existing static variables are (even re-using the same struct declaration).

Note: this is just a draft of one possible design, the intent of this issue is to highlight the fact that this issue has now come up multiple times, and it would be good to have a standard answer available.

----------
messages: 360766
nosy: eric.snow, ncoghlan, petr.viktorin, shihai1991
priority: normal
severity: normal
status: open
title: Design a subinterpreter friendly alternative to _Py_IDENTIFIER

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Mon Jan 27 09:28:51 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 27 Jan 2020 14:28:51 +0000
Subject: [issue39465] Design a subinterpreter friendly alternative to
 _Py_IDENTIFIER
In-Reply-To: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>
Message-ID: <1580135331.25.0.760803342048.issue39465@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Mon Jan 27 09:29:25 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jan 2020 14:29:25 +0000
Subject: [issue39464] Allow translating argument error messages
In-Reply-To: <1580133337.82.0.00677207154431.issue39464@roundup.psfhosted.org>
Message-ID: <1580135365.04.0.17014854413.issue39464@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +paul.j3, rhettinger
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39464>
_______________________________________

From report at bugs.python.org  Mon Jan 27 09:29:44 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jan 2020 14:29:44 +0000
Subject: [issue39464] Allow translating argparse error messages
In-Reply-To: <1580133337.82.0.00677207154431.issue39464@roundup.psfhosted.org>
Message-ID: <1580135384.46.0.820212667492.issue39464@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
title: Allow translating argument error messages -> Allow translating argparse error messages

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39464>
_______________________________________

From report at bugs.python.org  Mon Jan 27 09:45:08 2020
From: report at bugs.python.org (=?utf-8?q?Dominik_Miedzi=C5=84ski?=)
Date: Mon, 27 Jan 2020 14:45:08 +0000
Subject: [issue37625] Class variable is still accessible after class instance
 has been overwritten out
In-Reply-To: <1563486914.84.0.86753245558.issue37625@roundup.psfhosted.org>
Message-ID: <1580136308.07.0.372597665611.issue37625@roundup.psfhosted.org>


Change by Dominik Miedzi?ski <dominik at mdzn.pl>:


----------
nosy:  -miedzinski

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37625>
_______________________________________

From report at bugs.python.org  Mon Jan 27 09:57:17 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jan 2020 14:57:17 +0000
Subject: [issue37625] Class variable is still accessible after class instance
 has been overwritten out
In-Reply-To: <1563486914.84.0.86753245558.issue37625@roundup.psfhosted.org>
Message-ID: <1580137037.58.0.528948089066.issue37625@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg360765

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37625>
_______________________________________

From report at bugs.python.org  Mon Jan 27 10:00:14 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Jan 2020 15:00:14 +0000
Subject: [issue39463] ast.Constant, bytes, and ast.unparse
In-Reply-To: <1580125203.43.0.757991294489.issue39463@roundup.psfhosted.org>
Message-ID: <1580137214.88.0.915037569244.issue39463@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Maybe we should only offically allow things that can be generated by ast.parse?

Yes, I think this is the way to go. In the future, we can expand the function to support more things, but for the first release, it should be as much restrictive as possible so we can iterate safely without making backwards-incompatible changes. 

I will update the docs soon to reflect this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39463>
_______________________________________

From report at bugs.python.org  Mon Jan 27 10:01:53 2020
From: report at bugs.python.org (chris)
Date: Mon, 27 Jan 2020 15:01:53 +0000
Subject: [issue39466] Great
Message-ID: <1580137313.79.0.716991951607.issue39466@roundup.psfhosted.org>


New submission from chris <logingitsite at gmail.com>:

How do I start creating my  own code, is there tutorial for this?
https://logingit.com/amazon-from-a-to-z-www-atoz-amazon-work/

----------
messages: 360768
nosy: Nadas
priority: normal
severity: normal
status: open
title: Great

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39466>
_______________________________________

From report at bugs.python.org  Mon Jan 27 10:02:27 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 27 Jan 2020 15:02:27 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1580137347.59.0.747729732702.issue39453@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 4dbf2d8c6789a9b7299b142033073213604b8fdc by Pablo Galindo (Dong-hee Na) in branch 'master':
bpo-39453: Make list.__contains__ hold strong references to avoid crashes (GH-18181)
https://github.com/python/cpython/commit/4dbf2d8c6789a9b7299b142033073213604b8fdc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Mon Jan 27 10:07:42 2020
From: report at bugs.python.org (Cilyan Olowen)
Date: Mon, 27 Jan 2020 15:07:42 +0000
Subject: [issue38423] Event loop implementation docs advertise set_event_loop
 which doesn't work with asyncio.run
In-Reply-To: <1570641279.2.0.929881138502.issue38423@roundup.psfhosted.org>
Message-ID: <1580137662.93.0.671184820321.issue38423@roundup.psfhosted.org>


Cilyan Olowen <gaknar at gmail.com> added the comment:

It doesn't seem to work either for asyncio.get_event_loop, especially when using asyncio.wait(), the loop complains that 

"RuntimeError: Task <Task pending coro=<Event.wait() running at lib\asyncio\locks.py:293> cb=[_wait.<locals>._on_completion() at lib\asyncio\tasks.py:440]> got Future <Future pending> attached to a different loop"

----------
nosy: +Cilyan Olowen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38423>
_______________________________________

From report at bugs.python.org  Mon Jan 27 10:14:09 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jan 2020 15:14:09 +0000
Subject: [issue39466] Great
In-Reply-To: <1580137313.79.0.716991951607.issue39466@roundup.psfhosted.org>
Message-ID: <1580138049.12.0.958964989305.issue39466@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Please stop spamming the bug tracker with random messages.

----------
nosy: +xtreak
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39466>
_______________________________________

From report at bugs.python.org  Mon Jan 27 10:14:17 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jan 2020 15:14:17 +0000
Subject: [issue39466] Great
In-Reply-To: <1580138049.12.0.958964989305.issue39466@roundup.psfhosted.org>
Message-ID: <1580138057.63.0.636946027893.issue39466@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg360768

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39466>
_______________________________________

From report at bugs.python.org  Mon Jan 27 10:18:48 2020
From: report at bugs.python.org (Cilyan Olowen)
Date: Mon, 27 Jan 2020 15:18:48 +0000
Subject: [issue38423] Event loop implementation docs advertise set_event_loop
 which doesn't work with asyncio.run
In-Reply-To: <1570641279.2.0.929881138502.issue38423@roundup.psfhosted.org>
Message-ID: <1580138328.52.0.887218181631.issue38423@roundup.psfhosted.org>


Cilyan Olowen <gaknar at gmail.com> added the comment:

My bad, I did not check that asyncio.Event() was called before the application has a chance to properly set_event_loop with custom one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38423>
_______________________________________

From report at bugs.python.org  Mon Jan 27 10:35:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 15:35:35 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580139335.96.0.996406499296.issue39460@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Mon Jan 27 10:57:30 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 27 Jan 2020 15:57:30 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580140650.38.0.152704580287.issue39461@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Adding `os.environ` support makes sense to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 10:59:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 15:59:06 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580140746.35.0.778385293787.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The failure has been seen on other architectures on Fedora Rawhide when building the Python 3.8.1 package:
https://koji.fedoraproject.org/koji/taskinfo?taskID=40870434

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Mon Jan 27 11:04:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 16:04:06 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580141046.08.0.527389819869.issue39461@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Currently, os.environ behaves as a dictionary. When you put value into os.environ[key], os.environ[key] gives you back this value. If we start to convert value to a different type (convert something to str), it can be surprising.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 11:28:35 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 27 Jan 2020 16:28:35 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1580142515.67.0.822914529774.issue39453@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17579
pull_request: https://github.com/python/cpython/pull/18202

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Mon Jan 27 11:31:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 16:31:24 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580142684.69.0.237717174375.issue39459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Issue also seen when building Python 3.9.0a3 on Fedora Rawhide:
https://src.fedoraproject.org/rpms/python39/pull-request/16

Logs: https://jenkins-continuous-infra.apps.ci.centos.org/job/fedora-rawhide-pr-pipeline/2558/artifact/package-tests/logs/console.log

pythoninfo:

    CC.version: gcc (GCC) 10.0.1 20200126 (Red Hat 10.0.1-0.6)
    Py_DEBUG: No (sys.gettotalrefcount() missing)
    config[executable]: '/usr/bin/python3.9'
    config[module_search_paths]: ['/usr/lib64/python39.zip', '/usr/lib64/python3.9', '/usr/lib64/python3.9/lib-dynload']
    os.getcwd: /var/str/python/selftest
    os.getgid: 0
    os.getgrouplist: 0
    os.getgroups: 0
    os.getuid: 0
    os.login: root
    platform.architecture: 64bit ELF
    platform.libc_ver: glibc 2.30.9000
    platform.platform: Linux-5.5.0-0.rc6.git3.1.fc32.x86_64-x86_64-with-glibc2.30.9000
    platform.python_implementation: CPython
    pwd.getpwuid(0): pwd.struct_passwd(pw_name='root', pw_passwd='x', pw_uid=0, pw_gid=0, pw_gecos='root', pw_dir='/root', pw_shell='/bin/bash')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 11:32:49 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 27 Jan 2020 16:32:49 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580142769.7.0.833352590265.issue39461@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

True, but so is having Path objects not seemlessly usable.

Also, isn't os.environ a special case where all values should be strings?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 11:39:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 16:39:00 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580143140.09.0.533649135756.issue39459@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17580
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18203

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 11:41:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 16:41:56 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580143316.87.0.263160866975.issue39459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> https://src.fedoraproject.org/rpms/python39/pull-request/16
>     os.getuid: 0

Maybe this failure comes from the fact that the test suite was run as the root user. I wrote PR 18203 to log the effective uid and gid in pythoninfo, to learn more about this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 11:43:19 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 27 Jan 2020 16:43:19 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1580143399.94.0.870894932223.issue39453@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17581
pull_request: https://github.com/python/cpython/pull/18204

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Mon Jan 27 11:43:54 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Jan 2020 16:43:54 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580143434.92.0.0736207413393.issue39461@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Implicit conversion can also hide some bugs.

Semantically os.environ is an str to str mapping and os.environb is a bytes to bytes mapping.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 11:49:40 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 27 Jan 2020 16:49:40 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1580143780.71.0.702793583888.issue39453@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17582
pull_request: https://github.com/python/cpython/pull/18205

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Mon Jan 27 12:04:32 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jan 2020 17:04:32 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1580144672.15.0.891320450758.issue39453@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9e1ed518a576897f914227bf538bac426a02a081 by Miss Islington (bot) (Dong-hee Na) in branch 'master':
bpo-39453: Add testcase for bpo-39453 (GH-18202)
https://github.com/python/cpython/commit/9e1ed518a576897f914227bf538bac426a02a081


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Mon Jan 27 12:06:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 17:06:45 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580144805.93.0.691344235207.issue39459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4a46adc7746930c4589ee483cad88d3f8504c045 by Victor Stinner in branch 'master':
bpo-39459: test.pythoninfo logs effective uid/gid (GH-18203)
https://github.com/python/cpython/commit/4a46adc7746930c4589ee483cad88d3f8504c045


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 12:10:52 2020
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 27 Jan 2020 17:10:52 +0000
Subject: [issue39466] Spam
In-Reply-To: <1580138049.12.0.958964989305.issue39466@roundup.psfhosted.org>
Message-ID: <1580145052.87.0.993941176457.issue39466@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I've removed the `User` role from that account since all of its posts have been spam; it will no longer be able to post.

----------
nosy: +zach.ware
resolution: fixed -> not a bug
title: Great -> Spam

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39466>
_______________________________________

From report at bugs.python.org  Mon Jan 27 12:13:34 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 27 Jan 2020 17:13:34 +0000
Subject: [issue39453] Use-after-free in list contain
In-Reply-To: <1579962146.28.0.764462410957.issue39453@roundup.psfhosted.org>
Message-ID: <1580145214.64.0.781667549207.issue39453@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17583
pull_request: https://github.com/python/cpython/pull/18206

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39453>
_______________________________________

From report at bugs.python.org  Mon Jan 27 12:20:35 2020
From: report at bugs.python.org (David Edelsohn)
Date: Mon, 27 Jan 2020 17:20:35 +0000
Subject: [issue39248] test_distutils fails on PPC64 Fedora 3.x:
 /tmp/subprocess.py
In-Reply-To: <1578420731.23.0.752143109381.issue39248@roundup.psfhosted.org>
Message-ID: <1580145635.48.0.554343490369.issue39248@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

The file was created and owned by another user.  I have removed the file.  I have reached out to the user to find out why he is creating it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39248>
_______________________________________

From report at bugs.python.org  Mon Jan 27 12:36:34 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 27 Jan 2020 17:36:34 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580146594.23.0.610811262789.issue39461@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

True, but this example of implicit conversion is only for Path objects which are currently implicitly converted throughout the stdlib where appropriate, and this looks like one of those appropriate places.

I don't know enough about os.environb to offer an opinion on auto-conversion there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 12:39:50 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 27 Jan 2020 17:39:50 +0000
Subject: [issue38610] use-after-free in list object function
In-Reply-To: <1572241758.28.0.0734328499539.issue38610@roundup.psfhosted.org>
Message-ID: <1580146790.15.0.387747283215.issue38610@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17584
pull_request: https://github.com/python/cpython/pull/18207

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38610>
_______________________________________

From report at bugs.python.org  Mon Jan 27 12:40:43 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 27 Jan 2020 17:40:43 +0000
Subject: [issue38610] use-after-free in list object function
In-Reply-To: <1572241758.28.0.0734328499539.issue38610@roundup.psfhosted.org>
Message-ID: <1580146843.28.0.619643416885.issue38610@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38610>
_______________________________________

From report at bugs.python.org  Mon Jan 27 12:57:35 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jan 2020 17:57:35 +0000
Subject: [issue39466] Spam
In-Reply-To: <1580138049.12.0.958964989305.issue39466@roundup.psfhosted.org>
Message-ID: <1580147855.83.0.297574705786.issue39466@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Zachary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39466>
_______________________________________

From report at bugs.python.org  Mon Jan 27 13:14:11 2020
From: report at bugs.python.org (=?utf-8?b?aGVydsOp?=)
Date: Mon, 27 Jan 2020 18:14:11 +0000
Subject: [issue39467] Allow to deprecate CLI arguments in argparse
Message-ID: <1580148851.76.0.444481366951.issue39467@roundup.psfhosted.org>


New submission from herv? <herveberaud.pro at gmail.com>:

Today it's not possible to deprecate CLI arguments designed with argparse, it could be useful to introduce deprecation feature in argparse to allow developers to inform their apps's users when an argument is planed to be removed in the future.

----------
components: Library (Lib)
messages: 360786
nosy: 4383
priority: normal
severity: normal
status: open
title: Allow to deprecate CLI arguments in argparse
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39467>
_______________________________________

From report at bugs.python.org  Mon Jan 27 13:17:34 2020
From: report at bugs.python.org (=?utf-8?b?aGVydsOp?=)
Date: Mon, 27 Jan 2020 18:17:34 +0000
Subject: [issue39467] Allow to deprecate CLI arguments in argparse
In-Reply-To: <1580148851.76.0.444481366951.issue39467@roundup.psfhosted.org>
Message-ID: <1580149054.53.0.588554667947.issue39467@roundup.psfhosted.org>


Change by herv? <herveberaud.pro at gmail.com>:


----------
keywords: +patch
pull_requests: +17585
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18208

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39467>
_______________________________________

From report at bugs.python.org  Mon Jan 27 13:19:24 2020
From: report at bugs.python.org (Hakan)
Date: Mon, 27 Jan 2020 18:19:24 +0000
Subject: [issue39424] [easy] test_signal: test_pidfd_send_signal() uses
 deprecated assertRaisesRegexp() method
In-Reply-To: <1579712181.32.0.0974422649306.issue39424@roundup.psfhosted.org>
Message-ID: <1580149164.5.0.27234587867.issue39424@roundup.psfhosted.org>


Hakan <hakancelik96 at outlook.com> added the comment:

I want to work on this as my first contribution

----------
nosy: +hakancelik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39424>
_______________________________________

From report at bugs.python.org  Mon Jan 27 13:24:35 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 27 Jan 2020 18:24:35 +0000
Subject: [issue39467] Allow to deprecate CLI arguments in argparse
In-Reply-To: <1580148851.76.0.444481366951.issue39467@roundup.psfhosted.org>
Message-ID: <1580149475.9.0.197419642219.issue39467@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +djarb, paul.j3, rhettinger -4383

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39467>
_______________________________________

From report at bugs.python.org  Mon Jan 27 13:45:46 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 27 Jan 2020 18:45:46 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580150746.76.0.624120022932.issue39461@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Supporting __fspath__ for os.environ[b] makes it consistent with POSIX os.putenv, which already supports it via PyUnicode_FSConverter. For example:

    os.putenv(Path('spam'), Path('eggs'))
    getenv = ctypes.CDLL('libc.so.6').getenv
    getenv.restype = ctypes.c_char_p

    >>> getenv(b'spam')
    b'eggs'

For symmetry, os.putenv in Windows could be updated to support __fspath__. An old patch for bpo-28188 implements this, along with bytes support, via PyUnicode_FSDecoder. But bytes support would be limited to UTF-8 strings, so it wouldn't be as flexible as os.environb in POSIX, which supports arbitrary bytes except for embedded nulls.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 14:30:30 2020
From: report at bugs.python.org (Dino Viehland)
Date: Mon, 27 Jan 2020 19:30:30 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580153430.38.0.770152623717.issue39459@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

The curious thing about this is other tests in CircularImportTests are importing packages from test.test_import.data in the exact same way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 14:46:53 2020
From: report at bugs.python.org (Aurora)
Date: Mon, 27 Jan 2020 19:46:53 +0000
Subject: [issue39468] .python_history write permission improvements
Message-ID: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>


New submission from Aurora <auroralanes at pm.me>:

On a typical Linux system, if you run 'chattr +i /home/user/.python_history', and then run python, then exit, the following error message will be printed out:
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site.py", line 446, in write_history
    readline.write_history_file(history)
OSError: [Errno -1] Unknown error -1


With a simple improvement, the site module can check and suggest the user to run 'chattr -i' on the .python_history file.

Additionaly, I don't know if it's a good idea to automatically run 'chattr -i' in such a situation or not.

----------
components: Library (Lib)
messages: 360790
nosy: opensource-assist
priority: normal
severity: normal
status: open
title: .python_history write permission improvements
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Mon Jan 27 14:57:05 2020
From: report at bugs.python.org (Aurora)
Date: Mon, 27 Jan 2020 19:57:05 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580155025.22.0.641434765493.issue39468@roundup.psfhosted.org>


Aurora <auroralanes at pm.me> added the comment:

https://github.com/opensource-assist/cpython/blob/opensource-assist-patch-sitepy-1/Lib/site.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Mon Jan 27 14:58:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 19:58:51 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580155131.85.0.785588404413.issue39459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> AMD64 Fedora Stable Clang Installed 3.x:
> https://buildbot.python.org/all/#/builders/127/builds/212

So, I added effective uid/gid to pythoninfo, here you have:

os.getegid: 1000
os.geteuid: 1000
os.getgid: 1000
os.getgrouplist: 1000
os.getgroups: 1000
os.getresgid: (1000, 1000, 1000)
os.getresuid: (1000, 1000, 1000)
os.getuid: 1000

There is nothing related to root (uid 0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 14:59:52 2020
From: report at bugs.python.org (Aurora)
Date: Mon, 27 Jan 2020 19:59:52 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580155192.55.0.883065696389.issue39468@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
keywords: +patch
pull_requests: +17586
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18210

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:01:54 2020
From: report at bugs.python.org (Aurora)
Date: Mon, 27 Jan 2020 20:01:54 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580155314.8.0.407720148244.issue39468@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
pull_requests:  -17586

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:02:02 2020
From: report at bugs.python.org (Aurora)
Date: Mon, 27 Jan 2020 20:02:02 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580155322.82.0.946884665735.issue39468@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
pull_requests: +17589
pull_request: https://github.com/python/cpython/pull/18210

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:08:26 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jan 2020 20:08:26 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1580155706.86.0.39990071434.issue39430@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> When was this change made?

It has always been this way, so no change here. We have actually improved the situation over the years with attempts at better locking in importlib itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:09:47 2020
From: report at bugs.python.org (SilentGhost)
Date: Mon, 27 Jan 2020 20:09:47 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580155787.18.0.369471224245.issue39468@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

1. Your PR contains unrelated changes
2. Please test your code: submitting syntactically incorrect code just wastes everyone's time

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:12:23 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jan 2020 20:12:23 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580155943.15.0.561585807876.issue39461@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I don't think this should be done (and I honestly would have disagreed with the Popen change for its 'env' argument or any other place that is dealing with environment variables). Environment variables are strings, period, so they should be specified as such; explicit is better than implicit (and there isn't enough pragmatic benefit to override this in my opinion).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:16:10 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 27 Jan 2020 20:16:10 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580156170.94.0.0327788290606.issue39459@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Was the Makefile updated to install Lib/test/test_import/date/unwritable?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:25:54 2020
From: report at bugs.python.org (Dino Viehland)
Date: Mon, 27 Jan 2020 20:25:54 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580156754.01.0.939928590356.issue39459@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

Ahh, that's probably it Brett, I didn't know that was there, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:30:05 2020
From: report at bugs.python.org (Dino Viehland)
Date: Mon, 27 Jan 2020 20:30:05 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580157005.77.0.218631132087.issue39459@roundup.psfhosted.org>


Change by Dino Viehland <dinoviehland at gmail.com>:


----------
pull_requests: +17590
pull_request: https://github.com/python/cpython/pull/18211

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:41:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 20:41:44 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580157704.79.0.620445263459.issue39461@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I don't think this should be done (and I honestly would have disagreed with the Popen change for its 'env' argument or any other place that is dealing with environment variables). Environment variables are strings, period, so they should be specified as such; explicit is better than implicit (and there isn't enough pragmatic benefit to override this in my opinion).

I don't think that subprocess accepts fspath on purpose. It uses fsencode() because it's convenient to encode Unicode to the filesystem encoding using the right error handler.

It's a side effect of the commit c1cbeedf0c650c3f7c64f04479070d39e15e1baf. In fact, I'm opposed to this commit, but now it's too change to change it again :-)

os.putenv() is unrelated to os.environ. Calling os.putenv() does not update os.environ, whereas setting a key in os.environ calls internally os.putenv().

I like the idea of keeping os.environ as simple as a dict mapping strings to trings (in term of API, internally it's more complicated).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:58:08 2020
From: report at bugs.python.org (Jeff Edwards)
Date: Mon, 27 Jan 2020 20:58:08 +0000
Subject: [issue39469] Support for relative home path in pyvenv.cfg
Message-ID: <1580158688.69.0.521881077968.issue39469@roundup.psfhosted.org>


New submission from Jeff Edwards <jeff at edwardsj.com>:

Currently, the interpreter only supports absolute paths for the 'home' directory in the pyvenv.cfg file.  While this works when the interpreter is always installed at a fixed location, it impacts the portability of virtual environments and can make it notably more-difficult if multiple virtual environments are shipped with a shared interpreter and are intended to be portable and working in any directory.

Many of these issues can be solved for if 'home' can use a directory relative to the directory of the pyvenv.cfg file.  This is detected by the presence of a starting '.' in the value.

A common use-case for this is that a script-based tool (e.g. black or supervisor) may be shipped with a larger portable application where they are intended to share the same interpreter (to save on deployment size), but may have conflicting dependencies.  Since the application only depends on the executable scripts, those packages could be packaged into  their own virtual environments with their dependencies.

----------
components: Interpreter Core
messages: 360800
nosy: Jeff.Edwards
priority: normal
severity: normal
status: open
title: Support for relative home path in pyvenv.cfg
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39469>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:59:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 20:59:29 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580158769.4.0.165131374793.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17591
pull_request: https://github.com/python/cpython/pull/18212

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:00:34 2020
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Jan 2020 21:00:34 +0000
Subject: [issue39469] Support for relative home path in pyvenv.cfg
In-Reply-To: <1580158688.69.0.521881077968.issue39469@roundup.psfhosted.org>
Message-ID: <1580158834.96.0.768119550136.issue39469@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17592
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18213

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39469>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:02:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 27 Jan 2020 21:02:45 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580158965.64.0.163977786754.issue39461@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Path-like objects are now unintentionally accepted for many non-path things, like hostname in socket.sethostname() and username in os.initgroups(). I also think it was a mistake, and we should not make new mistakes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:03:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 21:03:42 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580159022.66.0.923324769935.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17594
pull_request: https://github.com/python/cpython/pull/18214

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Jan 27 15:54:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 20:54:48 +0000
Subject: [issue39248] test_distutils fails on PPC64 Fedora 3.x:
 /tmp/subprocess.py
In-Reply-To: <1578420731.23.0.752143109381.issue39248@roundup.psfhosted.org>
Message-ID: <1580158488.55.0.627923687658.issue39248@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The buildbot is back to green, thank you David :-)
https://buildbot.python.org/all/#/builders/8/builds/254

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39248>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:07:09 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 27 Jan 2020 21:07:09 +0000
Subject: [issue39282] python-config --embed documentation
In-Reply-To: <1578620661.54.0.572519425656.issue39282@roundup.psfhosted.org>
Message-ID: <1580159229.7.0.435248843739.issue39282@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

Leaving this for @victor to decide since he is the PR author.

----------
nosy: +nanjekyejoannah, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39282>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:22:53 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 27 Jan 2020 21:22:53 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580160173.28.0.468669244541.issue39461@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I honestly would have disagreed with the Popen change for its 'env' 
> argument or any other place that is dealing with environment
> variables

os.spawnve (Windows) and os.execve support __fspath__ for the env  dict partially due to me (bpo-28114), so sorry if that was the wrong decision. However, at least on the POSIX side, I was restoring previous behavior that aligned with POSIX os.putenv. An example of what's supported currently:

Windows:

    >>> path = os.environ['comspec']
    >>> argv = ['cmd', '/c', 'echo %SPAM%']
    >>> env = os.environ.copy()
    >>> env[Path('SPAM')] = Path('eggs')
    >>> os.spawnve(0, path, argv, env)
    eggs
    0

POSIX:

    >>> path = '/bin/bash'
    >>> argv = ['bash', '-c', 'echo $SPAM']
    >>> env = os.environ.copy()
    >>> env[Path('SPAM')] = Path('eggs')
    >>> os.spawnve(0, path, argv, env)
    eggs
    0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:26:46 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 27 Jan 2020 21:26:46 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580160406.15.0.892278786256.issue39461@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

The idea behind PEP 519 was to alleviate str(path_obj) calls between the os/program interface.  We can either make that as consistent as we can as we find places that still require the str(path_obj) idiom, or we can make users remember which ones do, and which ones don't, easily use a Path object.

In my opinion, having to remember is a very unpleasant and frustrating user experience.

Serhiy Storchaka:
----------------
> Path-like objects are now unintentionally accepted for many non-path
> things, like hostname in socket.sethostname() and username in
> os.initgroups(). I also think it was a mistake, and we should not
> make new mistakes.

There will always be ways for users to make mistakes when using API's.  Whether they passed a Path path to os.sethostname() or a string path to os.sethostbyname(), it's still their bug, and linters/type-checkers exist to help catch those kinds of bugs.

Brett Canon:
-----------
> Environment variables are strings, period, so they should be specified
> as such;

Out of curiosity, any idea how often non-strings are used to set os.environ, and so need explicit conversion?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:29:15 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 27 Jan 2020 21:29:15 +0000
Subject: [issue39430] tarfile.open(mode="r") race condition when importing lzma
In-Reply-To: <1579778138.71.0.872285273373.issue39430@roundup.psfhosted.org>
Message-ID: <1580160555.04.0.897536825918.issue39430@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Cool.  I appreciate all the work in this area, thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39430>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:34:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 21:34:10 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580160850.04.0.675467615791.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17595
pull_request: https://github.com/python/cpython/pull/18215

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:37:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 21:37:09 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580161029.92.0.283490106741.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a94c6b61aa5c09237b8105e5aee638cd54197b6f by Victor Stinner in branch 'master':
bpo-38631: Avoid Py_FatalError() in PyModule_Create2() (GH-18212)
https://github.com/python/cpython/commit/a94c6b61aa5c09237b8105e5aee638cd54197b6f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:37:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 21:37:47 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580161067.98.0.0197998892369.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 47ee8a6063c22ec272fe7a2d95d12f7811ebb48b by Victor Stinner in branch 'master':
bpo-38631: Avoid Py_FatalError() in _memory_release() (GH-18214)
https://github.com/python/cpython/commit/47ee8a6063c22ec272fe7a2d95d12f7811ebb48b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:50:47 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 27 Jan 2020 21:50:47 +0000
Subject: [issue39470] Indicate that os.makedirs is equivalent to Path.mkdir
Message-ID: <1580161847.67.0.0849845535184.issue39470@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

:func:`os.makedirs` is equivalent to ``mkdir -p`` and :meth:`Path.mkdir()` when given an optional *exist_ok* argument.

----------
messages: 360808
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Indicate that os.makedirs is equivalent to Path.mkdir

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39470>
_______________________________________

From report at bugs.python.org  Mon Jan 27 16:52:16 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 27 Jan 2020 21:52:16 +0000
Subject: [issue39470] Indicate that os.makedirs is equivalent to Path.mkdir
In-Reply-To: <1580161847.67.0.0849845535184.issue39470@roundup.psfhosted.org>
Message-ID: <1580161936.23.0.406977980915.issue39470@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch
pull_requests: +17596
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18216

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39470>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:00:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 22:00:39 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580162439.96.0.547705515017.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17597
pull_request: https://github.com/python/cpython/pull/18217

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:14:19 2020
From: report at bugs.python.org (Sebastian Berg)
Date: Mon, 27 Jan 2020 22:14:19 +0000
Subject: [issue39471] Meaning and clarification of PyBuffer_Release()
Message-ID: <1580163259.11.0.807397733698.issue39471@roundup.psfhosted.org>


New submission from Sebastian Berg <sebastian at sipsolutions.net>:

The current documentation of ``PyBuffer_Release()`` and the PEP is a bit fuzzy about what the function can and cannot do.

When an object exposes the buffer interface, I believe it should always return a `view` (in NumPy speak) of its own data, i.e. the data exposed by the object is also owned by it directly.

On the other hand the buffer view _itself_ has fields such as `strides`, etc. which may need allocating.

In other words, I think `PyBuffer_Release()` should be documented to deallocate/invalidate the `Py_buffer`. But, it *must not* invalidate the actual memory it points to. If I copy all information out of the `Py_buffer` and then free it, the copy must still be valid.

I think this is the intention, but it is not spelled out clear enough, it is also the reason for the behaviour of the "#s", etc. keyword argument parsers failing due to the code:

    if (pb != NULL && pb->bf_releasebuffer != NULL) {
        *errmsg = "read-only bytes-like object";
        return -1;
    }

which in turn currently means NumPy decides to _not_ implement bf_releasebuffer at all (leading to very ugly work arounds).

I am happy to make a PR, if we can get to a point where everyone is absolutely certain that the above interpretation was always correct, we could clean up a lot of code inside NumPy as well!

----------
components: C API
messages: 360809
nosy: seberg
priority: normal
severity: normal
status: open
title: Meaning and clarification of PyBuffer_Release()
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39471>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:16:03 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jan 2020 22:16:03 +0000
Subject: [issue30780] IDLE: configdialog - add tests for ConfigDialog GUI.
In-Reply-To: <1498516711.25.0.892352273971.issue30780@psf.upfronthosting.co.za>
Message-ID: <1580163363.7.0.663215068757.issue30780@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset dd023ad1619b6f1ab313986e8953eea32c18f50c by Terry Jan Reedy (Cheryl Sabella) in branch 'master':
bpo-30780: Add IDLE configdialog tests (#3592)
https://github.com/python/cpython/commit/dd023ad1619b6f1ab313986e8953eea32c18f50c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30780>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:16:12 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jan 2020 22:16:12 +0000
Subject: [issue30780] IDLE: configdialog - add tests for ConfigDialog GUI.
In-Reply-To: <1498516711.25.0.892352273971.issue30780@psf.upfronthosting.co.za>
Message-ID: <1580163372.94.0.0525524946581.issue30780@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17598
pull_request: https://github.com/python/cpython/pull/18218

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30780>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:18:00 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jan 2020 22:18:00 +0000
Subject: [issue30780] IDLE: configdialog - add tests for ConfigDialog GUI.
In-Reply-To: <1498516711.25.0.892352273971.issue30780@psf.upfronthosting.co.za>
Message-ID: <1580163480.12.0.517311198082.issue30780@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17599
pull_request: https://github.com/python/cpython/pull/18219

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30780>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:23:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 22:23:18 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580163798.73.0.888625127536.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d3a1de22705cc79d7e8a0f44c4f00255e58c8b20 by Victor Stinner in branch 'master':
bpo-38631: Avoid Py_FatalError() in _PyCodecRegistry_Init() (GH-18217)
https://github.com/python/cpython/commit/d3a1de22705cc79d7e8a0f44c4f00255e58c8b20


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:23:22 2020
From: report at bugs.python.org (Joannah Nanjekye)
Date: Mon, 27 Jan 2020 22:23:22 +0000
Subject: [issue39153] Clarify refcounting semantics of PyDict_SetItem[String]
In-Reply-To: <1577626439.88.0.846596028568.issue39153@roundup.psfhosted.org>
Message-ID: <1580163802.84.0.651611901282.issue39153@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch
pull_requests: +17600
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18220

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39153>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:24:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 22:24:17 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580163857.55.0.181836943122.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a27831351873bd7eff10863353d475c29fb0d7bb by Victor Stinner in branch 'master':
bpo-38631: Avoid Py_FatalError() in PyCode_New() (GH-18215)
https://github.com/python/cpython/commit/a27831351873bd7eff10863353d475c29fb0d7bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:25:10 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Jan 2020 22:25:10 +0000
Subject: [issue39467] Allow to deprecate CLI arguments in argparse
In-Reply-To: <1580148851.76.0.444481366951.issue39467@roundup.psfhosted.org>
Message-ID: <1580163910.02.0.565858134185.issue39467@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Will leave this open for a while so that many people can comment on the proposal before we act on it.

My initial take is:

* Having a way to deprecate seems useful.

* In practice, I haven't seen this done very much (in big tooling such as GCC perhaps, but everyday command-line tools don't seem to do this AFAICT).

* The warnings module is likely not the right implementation tool.  The warnings module doesn't make as much sense for CLIs as it does for libraries.  It particular, the warnings module is all about the ability of consumer code to filter, ignore, or escalate warnings.  Also, we've so far been good about minimizing inter-module dependencies so that start-up time remains fast.

* The PR is aggressive in providing *deprecated*, *deprecated_reason*, and *deprecated_pending*.  Perhaps a simpler hook or flag would suffice.  The overall module API is already large enough to be a barrier to learning all the features.

* There is some question as to whether this belongs in argparse at all or whether it should be in downstream, post-parsing logic.  For example:
     
    args = parser.parse_args()
    if args.throw:
         print('"throw" has been deprecated, use "toss" instead',
               file=sys.stderr)
    ..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39467>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:25:25 2020
From: report at bugs.python.org (Brian Quinlan)
Date: Mon, 27 Jan 2020 22:25:25 +0000
Subject: [issue39205] Hang when interpreter exits after
 ProcessPoolExecutor.shutdown(wait=False)
In-Reply-To: <1578086784.42.0.0982560626547.issue39205@roundup.psfhosted.org>
Message-ID: <1580163925.14.0.213687488247.issue39205@roundup.psfhosted.org>


Change by Brian Quinlan <brian at sweetapp.com>:


----------
keywords: +patch
pull_requests: +17601
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18221

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39205>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:28:22 2020
From: report at bugs.python.org (Sebastian Berg)
Date: Mon, 27 Jan 2020 22:28:22 +0000
Subject: [issue39471] Meaning and clarification of PyBuffer_Release()
In-Reply-To: <1580163259.11.0.807397733698.issue39471@roundup.psfhosted.org>
Message-ID: <1580164102.73.0.152404784517.issue39471@roundup.psfhosted.org>


Sebastian Berg <sebastian at sipsolutions.net> added the comment:

Hmmm, it seems I had missed this chunk of PEP 3118 before:

> Exporters will need to define a bf_releasebuffer function if they can re-allocate their memory, strides, shape, suboffsets, or format variables which they might share through the struct bufferinfo.

Which reads like the opposite of what I would like to see, unfortunately. Which I guess means that the parsing issue should be addressed differently. Opinions still welcome, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39471>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:31:40 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jan 2020 22:31:40 +0000
Subject: [issue30780] IDLE: configdialog - add tests for ConfigDialog GUI.
In-Reply-To: <1498516711.25.0.892352273971.issue30780@psf.upfronthosting.co.za>
Message-ID: <1580164300.72.0.517132110726.issue30780@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5aefee6f989821c5dc36d10a9cfd083d7aa737a5 by Miss Islington (bot) in branch '3.7':
bpo-30780: Add IDLE configdialog tests (GH-3592)
https://github.com/python/cpython/commit/5aefee6f989821c5dc36d10a9cfd083d7aa737a5


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30780>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:35:12 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jan 2020 22:35:12 +0000
Subject: [issue30780] IDLE: configdialog - add tests for ConfigDialog GUI.
In-Reply-To: <1498516711.25.0.892352273971.issue30780@psf.upfronthosting.co.za>
Message-ID: <1580164512.33.0.952164006018.issue30780@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7b57b15bd83879ee35f8758a84a7857a9968c145 by Miss Islington (bot) in branch '3.8':
bpo-30780: Add IDLE configdialog tests (GH-3592)
https://github.com/python/cpython/commit/7b57b15bd83879ee35f8758a84a7857a9968c145


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30780>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:38:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 22:38:21 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580164701.51.0.008488049057.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

There are still around 122 calls to Py_FatalError() in the master branch. But remaining ones are the hardest to remove. I close the issue, it's already better than previously.

Compare this number to 285 calls in Python 3.6.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:39:18 2020
From: report at bugs.python.org (Sebastian Berg)
Date: Mon, 27 Jan 2020 22:39:18 +0000
Subject: [issue39471] Meaning and clarification of PyBuffer_Release()
In-Reply-To: <1580163259.11.0.807397733698.issue39471@roundup.psfhosted.org>
Message-ID: <1580164758.79.0.779286735709.issue39471@roundup.psfhosted.org>


Sebastian Berg <sebastian at sipsolutions.net> added the comment:

I went through Python, `array` seems to not break the logic. pickling has a comment which specifically wants to run into the argument parsing corner case above (I am not sure that it is really important). However, `Modules/_testbuffer.c` (which is just test) actually does allocate new memory for the buffer!

I can be convinced that this is how it is supposed to be, but right now I am still not quite. The main idea is efficient no-copy data sharing. It is always possible to create a `to_memoryview()` method if a realloc was desired/necessary...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39471>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:50:43 2020
From: report at bugs.python.org (Peter O.)
Date: Mon, 27 Jan 2020 22:50:43 +0000
Subject: [issue39391] Nondeterministic Pydoc output on functions that have
 functions as default parameters
In-Reply-To: <1579475037.48.0.632958566945.issue39391@roundup.psfhosted.org>
Message-ID: <1580165443.18.0.981808790548.issue39391@roundup.psfhosted.org>


Peter O. <poccil14 at gmail.com> added the comment:

No, the use case I have in mind is storing outputs of the pydoc3 program -- as is -- in version control systems such as Git (e.g., running a command like "pydoc3 mymodule > mymodule_doc.txt").  The pydoc3 output is not further parsed by programs, or even "tested".

For example, adding "#doctest: +ELLIPSIS" as in the following example does not solve the problem in the opening post:


    def testfunc(a, m=d0): #doctest: +ELLIPSIS
       pass

----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39391>
_______________________________________

From report at bugs.python.org  Mon Jan 27 17:54:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 27 Jan 2020 22:54:51 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1580165691.13.0.0283726000781.issue38644@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17602
pull_request: https://github.com/python/cpython/pull/18222

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:00:47 2020
From: report at bugs.python.org (Eric Wieser)
Date: Mon, 27 Jan 2020 23:00:47 +0000
Subject: [issue39471] Meaning and clarification of PyBuffer_Release()
In-Reply-To: <1580163259.11.0.807397733698.issue39471@roundup.psfhosted.org>
Message-ID: <1580166047.84.0.901986445237.issue39471@roundup.psfhosted.org>


Change by Eric Wieser <wieser.eric at gmail.com>:


----------
nosy: +Eric Wieser

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39471>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:08:32 2020
From: report at bugs.python.org (Dino Viehland)
Date: Mon, 27 Jan 2020 23:08:32 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580166512.91.0.0133959149492.issue39459@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

I've added the files to the makefile and AMD64 Fedora Stable Clang Installed 3.x was passing.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:21:06 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jan 2020 23:21:06 +0000
Subject: [issue39392] Python Turtle is not filling alternate overlapping areas
 of a shape with same color
In-Reply-To: <1579497263.75.0.682788787706.issue39392@roundup.psfhosted.org>
Message-ID: <1580167266.83.0.382180891686.issue39392@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +17603
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18223

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39392>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:34:59 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jan 2020 23:34:59 +0000
Subject: [issue39472] IDLE: improve handling of int entry in settings dialog
Message-ID: <1580168099.75.0.367298873438.issue39472@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Spinoff from #31414, about int entry fields.  It claims: Note: a deeper problem is attaching a tracer that get called with each keystroke.  Using a StringVar avoids the error when the entry is blanked, but currently allows non-ints to be saved.  A better solution would be to not do the auto tracing, but use a IntVar and only call var_changed when the user 'leaves' the box, after checking for a count in a sane range.

Verify claim and proposed solution.

----------
assignee: terry.reedy
components: IDLE
messages: 360821
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: improve handling of int entry in settings dialog
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39472>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:36:51 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jan 2020 23:36:51 +0000
Subject: [issue31414] IDLE: Entry tests should delete before insert.
In-Reply-To: <1505099853.11.0.427045328648.issue31414@psf.upfronthosting.co.za>
Message-ID: <1580168211.33.0.66903245661.issue31414@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Opened #39472 for changes dialog itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31414>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:37:54 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jan 2020 23:37:54 +0000
Subject: [issue31414] IDLE: Entry tests should delete before insert.
In-Reply-To: <1505099853.11.0.427045328648.issue31414@psf.upfronthosting.co.za>
Message-ID: <1580168274.76.0.21009171095.issue31414@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31414>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:38:45 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jan 2020 23:38:45 +0000
Subject: [issue30780] IDLE: configdialog - add tests for ConfigDialog GUI.
In-Reply-To: <1498516711.25.0.892352273971.issue30780@psf.upfronthosting.co.za>
Message-ID: <1580168325.45.0.0263952115355.issue30780@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30780>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:41:24 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jan 2020 23:41:24 +0000
Subject: [issue39392] Python Turtle is not filling alternate overlapping areas
 of a shape with same color
In-Reply-To: <1579497263.75.0.682788787706.issue39392@roundup.psfhosted.org>
Message-ID: <1580168484.81.0.679928215238.issue39392@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 2824c45a0a020f12f27da7e7162e8636c21bf869 by Terry Jan Reedy in branch 'master':
bpo-39392: Turtle overlap fill depends on OS (#18223)
https://github.com/python/cpython/commit/2824c45a0a020f12f27da7e7162e8636c21bf869


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39392>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:41:36 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jan 2020 23:41:36 +0000
Subject: [issue39392] Python Turtle is not filling alternate overlapping areas
 of a shape with same color
In-Reply-To: <1579497263.75.0.682788787706.issue39392@roundup.psfhosted.org>
Message-ID: <1580168496.98.0.94506254101.issue39392@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17605
pull_request: https://github.com/python/cpython/pull/18225

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39392>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:41:31 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jan 2020 23:41:31 +0000
Subject: [issue39392] Python Turtle is not filling alternate overlapping areas
 of a shape with same color
In-Reply-To: <1579497263.75.0.682788787706.issue39392@roundup.psfhosted.org>
Message-ID: <1580168491.69.0.268042657854.issue39392@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17604
pull_request: https://github.com/python/cpython/pull/18224

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39392>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:46:31 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jan 2020 23:46:31 +0000
Subject: [issue39392] Python Turtle is not filling alternate overlapping areas
 of a shape with same color
In-Reply-To: <1579497263.75.0.682788787706.issue39392@roundup.psfhosted.org>
Message-ID: <1580168791.71.0.688616403874.issue39392@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 005b0596326cf1b4f17e8d38bfc3887d4486e564 by Miss Islington (bot) in branch '3.7':
bpo-39392: Turtle overlap fill depends on OS (GH-18223)
https://github.com/python/cpython/commit/005b0596326cf1b4f17e8d38bfc3887d4486e564


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39392>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:46:33 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 27 Jan 2020 23:46:33 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1580168793.4.0.599033229784.issue39390@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:


New changeset cf9d00554715febf21cf94950da4f42723b80498 by Giampaolo Rodola (mbarkhau) in branch '3.8':
[3.8] bpo-39390 shutil: fix argument types for ignore callback (GH-18122)
https://github.com/python/cpython/commit/cf9d00554715febf21cf94950da4f42723b80498


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:47:12 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 27 Jan 2020 23:47:12 +0000
Subject: [issue39392] Python Turtle is not filling alternate overlapping areas
 of a shape with same color
In-Reply-To: <1579497263.75.0.682788787706.issue39392@roundup.psfhosted.org>
Message-ID: <1580168832.53.0.771006440649.issue39392@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b487a8ed5bd267d62a05c3cab7def6b1f36999ea by Miss Islington (bot) in branch '3.8':
bpo-39392: Turtle overlap fill depends on OS (GH-18223)
https://github.com/python/cpython/commit/b487a8ed5bd267d62a05c3cab7def6b1f36999ea


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39392>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:48:05 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 27 Jan 2020 23:48:05 +0000
Subject: [issue39392] Python Turtle is not filling alternate overlapping areas
 of a shape with same color
In-Reply-To: <1579497263.75.0.682788787706.issue39392@roundup.psfhosted.org>
Message-ID: <1580168885.71.0.155828227669.issue39392@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39392>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:48:24 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 27 Jan 2020 23:48:24 +0000
Subject: [issue39390] shutil.copytree - 3.8 changed argument types of the
 ignore callback
In-Reply-To: <1579466446.68.0.178285979921.issue39390@roundup.psfhosted.org>
Message-ID: <1580168904.43.0.755579868081.issue39390@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
assignee: docs at python -> giampaolo.rodola
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39390>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:55:07 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Jan 2020 23:55:07 +0000
Subject: [issue39467] Allow to deprecate CLI arguments in argparse
In-Reply-To: <1580148851.76.0.444481366951.issue39467@roundup.psfhosted.org>
Message-ID: <1580169307.48.0.915492449935.issue39467@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Will leave this open for a while so that many people can comment on the proposal before we act on it.

My initial take is:

* Having a way to deprecate seems useful.

* In practice, I haven't seen this done very much (in big tooling such as GCC perhaps, but everyday command-line tools don't seem to do this AFAICT).

* The warnings module is likely not the right implementation tool.  The warnings module doesn't make as much sense for CLIs as it does for libraries.  In particular, the warnings module is all about the ability of consumer code to filter, ignore, or escalate warnings.  Also, we've so far been good about minimizing inter-module dependencies so that start-up time remains fast.

* The PR is aggressive in providing *deprecated*, *deprecated_reason*, and *deprecated_pending*.  Perhaps a simpler hook or flag would suffice.  The overall module API is already large enough to be a barrier to learning all the features.

* There is some question as to whether this belongs in argparse at all or whether it should be in downstream, post-parsing logic.  For example:

    parser.add_argument('--throw', action='store_true',
             help = '(deprecated use "toss" instead) causes ball to move')
    ...
    args = parser.parse_args()
    if args.throw:
         print('"throw" has been deprecated, use "toss" instead',
               file=sys.stderr)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39467>
_______________________________________

From report at bugs.python.org  Mon Jan 27 18:55:21 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 27 Jan 2020 23:55:21 +0000
Subject: [issue39467] Allow to deprecate CLI arguments in argparse
In-Reply-To: <1580148851.76.0.444481366951.issue39467@roundup.psfhosted.org>
Message-ID: <1580169321.61.0.617198496345.issue39467@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: https://bugs.python.org/msg360813

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39467>
_______________________________________

From report at bugs.python.org  Mon Jan 27 19:50:40 2020
From: report at bugs.python.org (Brian Quinlan)
Date: Tue, 28 Jan 2020 00:50:40 +0000
Subject: [issue39205] Hang when interpreter exits after
 ProcessPoolExecutor.shutdown(wait=False)
In-Reply-To: <1578086784.42.0.0982560626547.issue39205@roundup.psfhosted.org>
Message-ID: <1580172640.98.0.322730166364.issue39205@roundup.psfhosted.org>


Brian Quinlan <brian at sweetapp.com> added the comment:


New changeset 884eb89d4a5cc8e023deaa65001dfa74a436694c by Brian Quinlan in branch 'master':
bpo-39205: Tests that highlight a hang on ProcessPoolExecutor shutdown (#18221)
https://github.com/python/cpython/commit/884eb89d4a5cc8e023deaa65001dfa74a436694c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39205>
_______________________________________

From report at bugs.python.org  Mon Jan 27 20:40:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 01:40:13 +0000
Subject: [issue39205] multiprocessing: Hang when interpreter exits after
 ProcessPoolExecutor.shutdown(wait=False)
In-Reply-To: <1578086784.42.0.0982560626547.issue39205@roundup.psfhosted.org>
Message-ID: <1580175613.23.0.578925025019.issue39205@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: Hang when interpreter exits after ProcessPoolExecutor.shutdown(wait=False) -> multiprocessing: Hang when interpreter exits after ProcessPoolExecutor.shutdown(wait=False)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39205>
_______________________________________

From report at bugs.python.org  Mon Jan 27 20:50:59 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jan 2020 01:50:59 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1580176259.16.0.394690508242.issue36018@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +17606
pull_request: https://github.com/python/cpython/pull/18226

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Mon Jan 27 21:08:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 02:08:26 +0000
Subject: [issue39413] Implement os.unsetenv() on Windows
In-Reply-To: <1579617560.05.0.467186991348.issue39413@roundup.psfhosted.org>
Message-ID: <1580177306.54.0.202686456079.issue39413@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39413>
_______________________________________

From report at bugs.python.org  Mon Jan 27 21:16:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 02:16:13 +0000
Subject: [issue38797] x86-64 High Sierra 3.x buildbot worker fails to build
 Python: python.exe setup.py does crash with a bus error
In-Reply-To: <1573736285.84.0.0787194812002.issue38797@roundup.psfhosted.org>
Message-ID: <1580177773.63.0.150055453397.issue38797@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

High Sierra buildbot worker is gone.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38797>
_______________________________________

From report at bugs.python.org  Mon Jan 27 21:19:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 02:19:04 +0000
Subject: [issue38605] [typing] PEP 563: Postponed evaluation of annotations:
 enable it by default before Python 4.0
In-Reply-To: <1572192430.43.0.755831692199.issue38605@roundup.psfhosted.org>
Message-ID: <1580177944.17.0.737788848465.issue38605@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I started a thread on typing-sig:
https://mail.python.org/archives/list/typing-sig at python.org/thread/JG4IWHO3TZORNESR6ARXFL6OUZU2BEBX/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38605>
_______________________________________

From report at bugs.python.org  Mon Jan 27 21:20:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 02:20:56 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580178056.6.0.903271202672.issue39459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

commit 2528a6c3d0660c03ae43d796628462ccf8e58190
Author: Dino Viehland <dinoviehland at gmail.com>
Date:   Mon Jan 27 14:04:56 2020 -0800

    Add test.test_import.data.unwritable package to makefile (#18211)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 21:21:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 02:21:01 +0000
Subject: [issue39336] Immutable module type can't be used as package in custom
 loader
In-Reply-To: <1579037611.53.0.713710863743.issue39336@roundup.psfhosted.org>
Message-ID: <1580178061.72.0.641685106915.issue39336@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

commit 2528a6c3d0660c03ae43d796628462ccf8e58190
Author: Dino Viehland <dinoviehland at gmail.com>
Date:   Mon Jan 27 14:04:56 2020 -0800

    Add test.test_import.data.unwritable package to makefile (#18211)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39336>
_______________________________________

From report at bugs.python.org  Mon Jan 27 21:24:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 02:24:12 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580178252.34.0.826263381535.issue39459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I've added the files to the makefile and AMD64 Fedora Stable Clang Installed 3.x was passing.

Thanks for the fix! I didn't notice that only "Installed" buildbot workers were impacted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Mon Jan 27 21:31:55 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jan 2020 02:31:55 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1580178715.65.0.306193587101.issue36018@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 01bf2196d842fc20667c5336e0a7a77eb4fdc25c by Raymond Hettinger in branch 'master':
bpo-36018: Minor fixes to the NormalDist() examples and recipes. (GH-18226)
https://github.com/python/cpython/commit/01bf2196d842fc20667c5336e0a7a77eb4fdc25c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Mon Jan 27 21:32:01 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 02:32:01 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1580178721.45.0.937696043636.issue36018@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17607
pull_request: https://github.com/python/cpython/pull/18227

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Mon Jan 27 21:37:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 02:37:49 +0000
Subject: [issue38644] Pass explicitly tstate to function calls
In-Reply-To: <1572445884.39.0.966254854932.issue38644@roundup.psfhosted.org>
Message-ID: <1580179069.24.0.728954958497.issue38644@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 61f4db8c56ca4b7e60050d96ecc255cfb03d92a0 by Victor Stinner in branch 'master':
bpo-38644: Pass tstate in ceval.c (GH-18222)
https://github.com/python/cpython/commit/61f4db8c56ca4b7e60050d96ecc255cfb03d92a0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38644>
_______________________________________

From report at bugs.python.org  Mon Jan 27 22:40:18 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jan 2020 03:40:18 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1580182818.06.0.433049005103.issue36018@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 41f4dc3bcf30cb8362a062a26818311c704ea89f by Raymond Hettinger (Miss Islington (bot)) in branch '3.8':
bpo-36018: Minor fixes to the NormalDist() examples and recipes. (GH-18226) (GH-18227)
https://github.com/python/cpython/commit/41f4dc3bcf30cb8362a062a26818311c704ea89f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Mon Jan 27 23:10:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jan 2020 04:10:53 +0000
Subject: [issue21696] Idle: test configuration files
In-Reply-To: <1402258295.62.0.994323894939.issue21696@psf.upfronthosting.co.za>
Message-ID: <1580184653.81.0.0873037472008.issue21696@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The issue is obsolete with respect to the minimal test implied by the opening message.  At least two tests (added since this was written) read the .def files.

Some of the proposed tests are, now at least, redundant  For boolean tests like
    self.assertIn(get('editor-on-startup', 'bool'), (True, False))
a non-boolean value results in a Warning (treated like error), the assert, and remaining tests are skipped, and IDLD hangs.  Stripping strings should not be needed.

Some of the tests should be part of a startup check of default *and* user options.  Values should also be checked when changed (they mostly are).

Since new options have been added, some tests are missing.

I would like to have a 3-layer option map that can be used for both runtime change and the test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21696>
_______________________________________

From report at bugs.python.org  Tue Jan 28 02:10:48 2020
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 28 Jan 2020 07:10:48 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1580195448.72.0.740248691526.issue39298@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

I gave it a go.  And yup, I see a definite improvement: it jumped from 1,583,326,242 bytes/sec to 2,376,741,703 bytes/sec on my Intel laptop using AVX2.  A 50% improvement!

I also *think* I'm seeing a 10% improvement in ARM using NEON.  On my DE10-Nano board, BLAKE3 portable gets about 50mb/sec, and now BLAKE3 using NEON gets about 55mb/sec.  (Roughly.)  I might have goofed up on the old benchmarks though, or just not written down the final correct numbers.

I observed no statistically significant performance change in the no-SIMD builds on Intel and ARM.

p.s. in my previous comment with that table of benchmarks I said "mb/sec".  I meant "bytes/sec".  Oops!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Tue Jan 28 02:17:04 2020
From: report at bugs.python.org (DarkTrick)
Date: Tue, 28 Jan 2020 07:17:04 +0000
Subject: [issue39473] Enable import behavior consistency option
Message-ID: <1580195824.75.0.658735928246.issue39473@roundup.psfhosted.org>


New submission from DarkTrick <notebook22312 at gmail.com>:

Matter:
========
`import`s are not handled the same throughout the different ways of calling.


Current situation:
===================
The resolution of `import` is dependant on the way of calling the script. 
Three ways of calling a script are shown below:
1) python myscript.py       # as script in cwd
2) python -m myscript       # as module in cwd
3) python -m src.myscript   # as module in subpackage of cwd

Given the following situation:

./src
|
|---main.py
|    |_________________________________
|    | from subdir.funca import funcA  |
|    | funca()                         |
|    |_________________________________|
|
|---subdir
      |
      |--- __init__.py
      |
      |--- funca.py
      |       |____________________________
      |       | from .funcb import funcB   |
      |       | def funcA():               |
      |       |    funcb()                 |
      |       |____________________________|
      |
      |
      |--- funcb.py
              |____________________________
              | def funcB():               |
              |    print("funcB")          |
              |____________________________|           

(A) The following call will succeed:
`./src>python -m main`

(B) The following call will succeed:
`./src>python main.py`

(C) The following call will succeed:
`./src>python -m subdir.funca

(D) The following call will not succeed:
`./src>python ./subdir/funca.py

(E) The following call will not succeed:
`./src/subdir>python funca.py


Suggestion:
===========
Supply a functionality / an option that will allow all of A~E to succeed. 

S1) So it doesn't matter, if the script is called with or without the -m option (D)
S2) So a toplevel script can refer to the package it's placed in by ".", even if called direclty (E)


Implementation idea:
=====================
Problem: The current import logic can't be change for compatibility reasons. And maybe it should not. 
Therefore I thought of an option within the python script like
`Option treatAsModule`  
or
`Option relImports`

If such an option would be given, the python interpreter would handle imports differently.

----------
components: Interpreter Core
messages: 360839
nosy: bluelantern
priority: normal
severity: normal
status: open
title: Enable import behavior consistency option
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39473>
_______________________________________

From report at bugs.python.org  Tue Jan 28 02:18:39 2020
From: report at bugs.python.org (CRYSTAL)
Date: Tue, 28 Jan 2020 07:18:39 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1580195919.37.0.440611465901.issue22831@roundup.psfhosted.org>


Change by CRYSTAL <Hinsonlcrystal at gmail.com>:


----------
components: +Build
nosy: +Hinsonlcrystal -Arfrever, berker.peksag, dstufft, eric.araujo, ezio.melotti, martin.panter, python-dev, rhettinger, serhiy.storchaka, vstinner
type: resource usage -> security
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Tue Jan 28 02:26:40 2020
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 28 Jan 2020 07:26:40 +0000
Subject: [issue39298] add BLAKE3 to hashlib
In-Reply-To: <1578716860.16.0.194711020268.issue39298@roundup.psfhosted.org>
Message-ID: <1580196400.05.0.610602309505.issue39298@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

I just tried it with clang, and uff-da!  2,737,446,868 bytes/sec!

p.s. I compiled with -O3 for both gcc and clang

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39298>
_______________________________________

From report at bugs.python.org  Tue Jan 28 02:52:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jan 2020 07:52:46 +0000
Subject: [issue14074] argparse allows nargs>1 for positional arguments but
 doesn't allow metavar to be a tuple
In-Reply-To: <1329845918.75.0.31962840333.issue14074@psf.upfronthosting.co.za>
Message-ID: <1580197966.8.0.93293255141.issue14074@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-0 on going forward with this.  AFAICT, no one has requested tuple support (the OP just wanted better error handling).  And more fined grained control can already be had just by specifying separate positional arguments.

Paul suggested that it may be a better plan to just disallow tuple metavars and to give a better error message as the OP suggested.  That makes sense to me.

----------
nosy: +rhettinger
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14074>
_______________________________________

From report at bugs.python.org  Tue Jan 28 02:53:43 2020
From: report at bugs.python.org (CRYSTAL)
Date: Tue, 28 Jan 2020 07:53:43 +0000
Subject: [issue24666] Buffered I/O does not take file position into account
 when reading blocks
In-Reply-To: <1437282046.06.0.196054163473.issue24666@psf.upfronthosting.co.za>
Message-ID: <1580198023.58.0.443483373053.issue24666@roundup.psfhosted.org>


Change by CRYSTAL <Hinsonlcrystal at gmail.com>:


----------
assignee:  -> docs at python
components: +2to3 (2.x to 3.x conversion tool), Build, Cross-Build, Documentation, Extension Modules, FreeBSD, Installation, Interpreter Core, Library (Lib), SSL, Tests, Unicode, ctypes
nosy: +Alex.Willmer, docs at python, ezio.melotti, koobs, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24666>
_______________________________________

From report at bugs.python.org  Tue Jan 28 03:06:00 2020
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 28 Jan 2020 08:06:00 +0000
Subject: [issue39432] Distutils generates the wrong export symbol for unicode
 module names
In-Reply-To: <1579787295.61.0.899007188072.issue39432@roundup.psfhosted.org>
Message-ID: <1580198760.95.0.0888632643328.issue39432@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39432>
_______________________________________

From report at bugs.python.org  Tue Jan 28 03:16:56 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 28 Jan 2020 08:16:56 +0000
Subject: [issue39391] Nondeterministic Pydoc output on functions that have
 functions as default parameters
In-Reply-To: <1579475037.48.0.632958566945.issue39391@roundup.psfhosted.org>
Message-ID: <1580199416.85.0.448643862432.issue39391@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Serhiy is right, I doubt if we can do something here.
A function address is a part of its __repr__() output.

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39391>
_______________________________________

From report at bugs.python.org  Tue Jan 28 03:29:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jan 2020 08:29:09 +0000
Subject: [issue39391] Nondeterministic Pydoc output on functions that have
 functions as default parameters
In-Reply-To: <1579475037.48.0.632958566945.issue39391@roundup.psfhosted.org>
Message-ID: <1580200149.78.0.566173509532.issue39391@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Even if we change the repr of functions (I like this idea), this will not solve the general problem: many reprs contain an object id.

In your case I suggest to post-process the pydoc output and replace parts matching ' at 0x[0-9a-fA-F]+'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39391>
_______________________________________

From report at bugs.python.org  Tue Jan 28 03:41:48 2020
From: report at bugs.python.org (Batuhan)
Date: Tue, 28 Jan 2020 08:41:48 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird on
 attribute access
Message-ID: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>


New submission from Batuhan <batuhanosmantaskaya at gmail.com>:

Python 3.9.0a2+ (heads/master:65ecc390c1, Jan 26 2020, 15:39:11) 
[GCC 9.2.1 20191008] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> source = "(2+2).source"
>>> ast.get_source_segment(source, ast.parse(source).body[0].value)
'2+2).source'
>>> source = "(2+2)[1]"
>>> ast.get_source_segment(source, ast.parse(source).body[0].value)
'2+2)[1]'

I can prepare a patch to extend attribute's col_offset into parens if it is any if approved.

----------
components: Interpreter Core
messages: 360844
nosy: BTaskaya, benjamin.peterson, pablogsal
priority: normal
severity: normal
status: open
title: col_offset for parenthesized expressions looks weird on attribute access
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Tue Jan 28 03:43:18 2020
From: report at bugs.python.org (Batuhan)
Date: Tue, 28 Jan 2020 08:43:18 +0000
Subject: [issue39474] col_offset for parenthesized expressions looks weird
In-Reply-To: <1580200908.73.0.745179365649.issue39474@roundup.psfhosted.org>
Message-ID: <1580200998.04.0.474677504366.issue39474@roundup.psfhosted.org>


Change by Batuhan <batuhanosmantaskaya at gmail.com>:


----------
title: col_offset for parenthesized expressions looks weird on attribute access -> col_offset for parenthesized expressions looks weird
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39474>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:14:51 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Tue, 28 Jan 2020 09:14:51 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580202891.39.0.39167965153.issue39460@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

In Fedora, this has started happening after the update of the following packages:

https://koschei.fedoraproject.org/build/7758715

 gcc
10.0.1-0.3.fc32 (in fact, there was gcc 9 in there, the report is maybe broken)
10.0.1-0.4.fc32

 libuuid
2.35-0.5.fc32
2.35-1.fc32

 glibc
2.30.9000-30.fc32
2.30.9000-31.fc32

 libselinux
3.0-1.fc32
3.0-2.fc32

 libblkid
2.35-0.5.fc32
2.35-1.fc32

 libgomp
10.0.1-0.3.fc32
10.0.1-0.4.fc32

 util-linux
2.35-0.5.fc32
2.35-1.fc32

 libmount
2.35-0.5.fc32
2.35-1.fc32

 libsmartcols
2.35-0.5.fc32
2.35-1.fc32

 libfdisk
2.35-0.5.fc32
2.35-1.fc32

----------
nosy: +hroncok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:20:10 2020
From: report at bugs.python.org (CRYSTAL)
Date: Tue, 28 Jan 2020 09:20:10 +0000
Subject: [issue39460] README.md
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580203210.61.0.758302422051.issue39460@roundup.psfhosted.org>


Change by CRYSTAL <Hinsonlcrystal at gmail.com>:


----------
assignee:  -> docs at python
components: +Build, Cross-Build, Documentation, Installation, Interpreter Core, Library (Lib), SSL, Unicode, Windows
nosy: +Alex.Willmer, Hinsonlcrystal, docs at python, ezio.melotti, paul.moore, steve.dower, tim.golden, zach.ware -David.Edelsohn, Dormouse759, hroncok
title: test_zipfile: test_add_file_after_2107() fails on s390x Fedora Rawhide 3.x -> README.md
type:  -> security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:42:11 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 09:42:11 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1580204531.64.0.333161501038.issue36264@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset c45a2aa9e255b5c7c211faa79f6b23895b64ab27 by Steve Dower (Christoph Reiter) in branch 'master':
bpo-38883: Don't use POSIX `$HOME` in `pathlib.Path.home/expanduser` on Windows (GH-17961)
https://github.com/python/cpython/commit/c45a2aa9e255b5c7c211faa79f6b23895b64ab27


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:42:13 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 09:42:13 +0000
Subject: [issue38883] Path.home() should ignore HOME env var like
 os.path.expanduser()
In-Reply-To: <1574361912.09.0.220955326522.issue38883@roundup.psfhosted.org>
Message-ID: <1580204533.03.0.784157735384.issue38883@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17608
pull_request: https://github.com/python/cpython/pull/18229

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38883>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:42:11 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 09:42:11 +0000
Subject: [issue38883] Path.home() should ignore HOME env var like
 os.path.expanduser()
In-Reply-To: <1574361912.09.0.220955326522.issue38883@roundup.psfhosted.org>
Message-ID: <1580204531.81.0.085951604244.issue38883@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset c45a2aa9e255b5c7c211faa79f6b23895b64ab27 by Steve Dower (Christoph Reiter) in branch 'master':
bpo-38883: Don't use POSIX `$HOME` in `pathlib.Path.home/expanduser` on Windows (GH-17961)
https://github.com/python/cpython/commit/c45a2aa9e255b5c7c211faa79f6b23895b64ab27


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38883>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:42:13 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 09:42:13 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1580204533.12.0.441537198859.issue36264@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17609
pull_request: https://github.com/python/cpython/pull/18229

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:42:46 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 09:42:46 +0000
Subject: [issue39393] Misleading error message upon dependent DLL resolution
 failure
In-Reply-To: <1579512450.11.0.864670825995.issue39393@roundup.psfhosted.org>
Message-ID: <1580204566.78.0.333159242868.issue39393@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 13c1c3556f2c12d0be2af890fabfbf44280b845c by Steve Dower (Zackery Spytz) in branch 'master':
bpo-39393: Misleading error message on dependent DLL resolution failure (GH-18093)
https://github.com/python/cpython/commit/13c1c3556f2c12d0be2af890fabfbf44280b845c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39393>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:42:55 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 09:42:55 +0000
Subject: [issue39393] Misleading error message upon dependent DLL resolution
 failure
In-Reply-To: <1579512450.11.0.864670825995.issue39393@roundup.psfhosted.org>
Message-ID: <1580204575.62.0.164201235022.issue39393@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17610
pull_request: https://github.com/python/cpython/pull/18230

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39393>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:43:09 2020
From: report at bugs.python.org (nova)
Date: Tue, 28 Jan 2020 09:43:09 +0000
Subject: [issue39475] window.getmaxyx() doesn't return updated height when
 window is resized
Message-ID: <1580204589.93.0.986649856634.issue39475@roundup.psfhosted.org>


New submission from nova <nova.parker at gmx.com>:

Package : python(v3.6.9)
Severity: normal

When a window object has been created using curses.newwin(), increasing
the terminal size produces the KEY_RESIZE events, but getmaxyx() returns
the previous terminal size. Only by decreasing the terminal size does it
return the correct terminal dimensions.

Attachment includes:
1. video demonstrating the effect

Following is the script to reproduce the effect:

import curses

def init_curses():
    curses.initscr()
    window = curses.newwin(curses.LINES - 1, curses.COLS, 0, 0)

    # window = curses.initscr()

    curses.raw()
    curses.noecho()
    curses.cbreak()
    window.keypad(True)

    return window

def restore_terminal(window):
    curses.noraw()
    curses.nocbreak()
    window.keypad(False)
    curses.echo()
    curses.endwin()

def main():
    try:
        window = init_curses()
        resize_no = 0
        maxy, maxx = window.getmaxyx()

        dimension_string = "resize_no: " + str(resize_no) + ". maxy: " + str(maxy) + "; maxx: " + str(maxx) + '\n'
        window.addstr(dimension_string)

        while True:
            ch = window.getch()
            window.clear()

            if ch == curses.KEY_RESIZE:
                resize_no += 1

                maxy, maxx = window.getmaxyx()
                dimension_string = "resize_no: " + str(resize_no) + ". maxy: " + str(maxy) + "; maxx: " + str(maxx) + '\n'
                window.addstr(dimension_string)


    finally:
        restore_terminal(window)

if __name__ == '__main__':
    main()

----------
components: Extension Modules
files: bug_curses.mp4
messages: 360849
nosy: nova
priority: normal
severity: normal
status: open
title: window.getmaxyx() doesn't return updated height when window is resized
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file48868/bug_curses.mp4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39475>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:44:15 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 09:44:15 +0000
Subject: [issue38704] Prevent installation on unsupported Windows versions
In-Reply-To: <1572983678.12.0.905160936522.issue38704@roundup.psfhosted.org>
Message-ID: <1580204655.62.0.797656573608.issue38704@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Zackery - I left you a comment on the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38704>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:44:52 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 09:44:52 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580204692.7.0.0191667410435.issue39401@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:57:36 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 09:57:36 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580205456.76.0.477413299696.issue39401@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +17611
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/18231

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:58:31 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 09:58:31 +0000
Subject: [issue39393] Misleading error message upon dependent DLL resolution
 failure
In-Reply-To: <1579512450.11.0.864670825995.issue39393@roundup.psfhosted.org>
Message-ID: <1580205511.58.0.433580696304.issue39393@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks, Zackery!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39393>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:59:05 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 09:59:05 +0000
Subject: [issue38883] Path.home() should ignore HOME env var like
 os.path.expanduser()
In-Reply-To: <1574361912.09.0.220955326522.issue38883@roundup.psfhosted.org>
Message-ID: <1580205545.75.0.80263531264.issue38883@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks, Christoph!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38883>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:59:47 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 09:59:47 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1580205587.52.0.434088157687.issue36264@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 595b516965ee88b817dc1b3d7713e1f3f263634d by Miss Islington (bot) in branch '3.8':
bpo-38883: Don't use POSIX `$HOME` in `pathlib.Path.home/expanduser` on Windows (GH-17961)
https://github.com/python/cpython/commit/595b516965ee88b817dc1b3d7713e1f3f263634d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Jan 28 04:59:47 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 09:59:47 +0000
Subject: [issue38883] Path.home() should ignore HOME env var like
 os.path.expanduser()
In-Reply-To: <1574361912.09.0.220955326522.issue38883@roundup.psfhosted.org>
Message-ID: <1580205587.64.0.869184672158.issue38883@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 595b516965ee88b817dc1b3d7713e1f3f263634d by Miss Islington (bot) in branch '3.8':
bpo-38883: Don't use POSIX `$HOME` in `pathlib.Path.home/expanduser` on Windows (GH-17961)
https://github.com/python/cpython/commit/595b516965ee88b817dc1b3d7713e1f3f263634d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38883>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:00:20 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 10:00:20 +0000
Subject: [issue39393] Misleading error message upon dependent DLL resolution
 failure
In-Reply-To: <1579512450.11.0.864670825995.issue39393@roundup.psfhosted.org>
Message-ID: <1580205620.47.0.628380761625.issue39393@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 46735c7e101753769e31c69a36d0030bb056a162 by Miss Islington (bot) in branch '3.8':
bpo-39393: Misleading error message on dependent DLL resolution failure (GH-18093)
https://github.com/python/cpython/commit/46735c7e101753769e31c69a36d0030bb056a162


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39393>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:02:29 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 10:02:29 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580205749.63.0.252630140534.issue39401@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +17612
pull_request: https://github.com/python/cpython/pull/18232

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:05:38 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 10:05:38 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580205938.15.0.034491904188.issue39401@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +17613
pull_request: https://github.com/python/cpython/pull/18233

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:06:21 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 10:06:21 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580205981.56.0.140409342969.issue39401@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +17614
pull_request: https://github.com/python/cpython/pull/18234

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:12:35 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 28 Jan 2020 10:12:35 +0000
Subject: [issue39287] Document UTF-8 mode in the using/windows.
In-Reply-To: <1578658299.42.0.446573986531.issue39287@roundup.psfhosted.org>
Message-ID: <1580206355.2.0.270316590268.issue39287@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 148610d88a2785751ed435a4e60f07a9f1bc50a6 by Inada Naoki in branch 'master':
bpo-39287: Doc: Add UTF-8 mode section in using/windows. (GH-17935)
https://github.com/python/cpython/commit/148610d88a2785751ed435a4e60f07a9f1bc50a6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39287>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:12:44 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 10:12:44 +0000
Subject: [issue39287] Document UTF-8 mode in the using/windows.
In-Reply-To: <1578658299.42.0.446573986531.issue39287@roundup.psfhosted.org>
Message-ID: <1580206364.32.0.272164147613.issue39287@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17615
pull_request: https://github.com/python/cpython/pull/18235

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39287>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:12:51 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 10:12:51 +0000
Subject: [issue39287] Document UTF-8 mode in the using/windows.
In-Reply-To: <1578658299.42.0.446573986531.issue39287@roundup.psfhosted.org>
Message-ID: <1580206371.36.0.552643241554.issue39287@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17616
pull_request: https://github.com/python/cpython/pull/18236

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39287>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:17:30 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 10:17:30 +0000
Subject: [issue39287] Document UTF-8 mode in the using/windows.
In-Reply-To: <1578658299.42.0.446573986531.issue39287@roundup.psfhosted.org>
Message-ID: <1580206650.93.0.234303625745.issue39287@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5a49ccac443ae84b8e142473a659c73032e9fe53 by Miss Islington (bot) in branch '3.7':
bpo-39287: Doc: Add UTF-8 mode section in using/windows. (GH-17935)
https://github.com/python/cpython/commit/5a49ccac443ae84b8e142473a659c73032e9fe53


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39287>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:18:01 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 10:18:01 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580206681.37.0.865348780305.issue39401@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

For clarity, I'm removing 3.9 from the affected versions. This version does not support Windows 7, and only Windows 7 is vulnerable to this DLL hijack.

Also submitting the CVE request.

----------
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:18:13 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 10:18:13 +0000
Subject: [issue39287] Document UTF-8 mode in the using/windows.
In-Reply-To: <1578658299.42.0.446573986531.issue39287@roundup.psfhosted.org>
Message-ID: <1580206693.5.0.176919128208.issue39287@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cee5da861091cdaca99f0636af7ab8c4b0274e5f by Miss Islington (bot) in branch '3.8':
bpo-39287: Doc: Add UTF-8 mode section in using/windows. (GH-17935)
https://github.com/python/cpython/commit/cee5da861091cdaca99f0636af7ab8c4b0274e5f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39287>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:28:51 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 28 Jan 2020 10:28:51 +0000
Subject: [issue39287] Document UTF-8 mode in the using/windows.
In-Reply-To: <1578658299.42.0.446573986531.issue39287@roundup.psfhosted.org>
Message-ID: <1580207331.18.0.184188363876.issue39287@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39287>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:29:20 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 10:29:20 +0000
Subject: [issue38092] environment variables not passed correctly using new
 virtualenv launching in windows and python3.7+
In-Reply-To: <1568122359.92.0.800539114246.issue38092@roundup.psfhosted.org>
Message-ID: <1580207360.55.0.153637907633.issue38092@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 6990d1b6131873c7f0913908162e4c723d00ea19 by Steve Dower (Adam Meily) in branch '3.7':
bpo-38092: Reduce overhead when using multiprocessing in a Windows virtual environment (GH-16098)
https://github.com/python/cpython/commit/6990d1b6131873c7f0913908162e4c723d00ea19


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38092>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:31:53 2020
From: report at bugs.python.org (=?utf-8?b?aGVydsOp?=)
Date: Tue, 28 Jan 2020 10:31:53 +0000
Subject: [issue39467] Allow to deprecate CLI arguments in argparse
In-Reply-To: <1580148851.76.0.444481366951.issue39467@roundup.psfhosted.org>
Message-ID: <1580207513.47.0.554519949479.issue39467@roundup.psfhosted.org>


herv? <herveberaud.pro at gmail.com> added the comment:

First, thanks Raymond for your worth useful comment.

* Concerning the usage of the warning module what do you suggest to use then?  To use "print"? 

* Concerning "hook or flag" and the 3 new params in my PR, I think developers would appreciate to give a customized message to their users to inform that something will be removed for X reasons in the X release. The "pending" notion could be removed to keep the API lightweight, but with a well documented feature I don't seen terrible thing to understand here, maybe we need to put more effort on documentation and example (related to my changes).

* Concerning the fact to move deprecation management outside the declaration of the argument, I think it could be misleading to deprecate something in another place in the code, in other words it could introduce some more difficulties to understand the code. If the deprecation is declared in the argument declaration then all the info are centralized in one place and the parser know what to do in this situation.

Thoughts?

----------
nosy: +4383

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39467>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:34:03 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Jan 2020 10:34:03 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580207643.61.0.0182810323281.issue39460@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
assignee: docs at python -> 
components:  -Build, Cross-Build, Documentation, Installation, Interpreter Core, Library (Lib), SSL, Unicode, Windows
nosy: +David.Edelsohn, Dormouse759, hroncok -Alex.Willmer, Hinsonlcrystal, docs at python, ezio.melotti, paul.moore, steve.dower, tim.golden, zach.ware
title: README.md -> test_zipfile: test_add_file_after_2107() fails on s390x Fedora Rawhide 3.x
type: security -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:34:26 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 10:34:26 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
In-Reply-To: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>
Message-ID: <1580207666.57.0.585904598865.issue39439@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 0be3246d4f9c8eddcd55491901d95b09fe163f15 by Steve Dower (Adam Meily) in branch 'master':
bpo-39439: Fix multiprocessing spawn path in a venv on Windows (GH-18158)
https://github.com/python/cpython/commit/0be3246d4f9c8eddcd55491901d95b09fe163f15


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:34:50 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 10:34:50 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
In-Reply-To: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>
Message-ID: <1580207690.88.0.772658772575.issue39439@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17617
pull_request: https://github.com/python/cpython/pull/18237

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:35:05 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 10:35:05 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
In-Reply-To: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>
Message-ID: <1580207705.3.0.140624928495.issue39439@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17618
pull_request: https://github.com/python/cpython/pull/18238

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:36:41 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 10:36:41 +0000
Subject: [issue38092] environment variables not passed correctly using new
 virtualenv launching in windows and python3.7+
In-Reply-To: <1568122359.92.0.800539114246.issue38092@roundup.psfhosted.org>
Message-ID: <1580207801.19.0.345421782551.issue38092@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Fixed via issue39439

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38092>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:37:17 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 28 Jan 2020 10:37:17 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
In-Reply-To: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>
Message-ID: <1580207837.35.0.228617940641.issue39439@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution: duplicate -> fixed
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:52:50 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 28 Jan 2020 10:52:50 +0000
Subject: [issue39439] Windows Multiprocessing in Virtualenv: sys.prefix is
 incorrect
In-Reply-To: <1579813490.23.0.271185160871.issue39439@roundup.psfhosted.org>
Message-ID: <1580208770.81.0.168312836905.issue39439@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dbb37aac1428ddcba784d9ddc77c1708c391aa80 by Miss Islington (bot) in branch '3.8':
bpo-39439: Fix multiprocessing spawn path in a venv on Windows (GH-18158)
https://github.com/python/cpython/commit/dbb37aac1428ddcba784d9ddc77c1708c391aa80


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39439>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:59:10 2020
From: report at bugs.python.org (Kubilay Kocak)
Date: Tue, 28 Jan 2020 10:59:10 +0000
Subject: [issue24666] Buffered I/O does not take file position into account
 when reading blocks
In-Reply-To: <1437282046.06.0.196054163473.issue24666@psf.upfronthosting.co.za>
Message-ID: <1580209150.3.0.742670525021.issue24666@roundup.psfhosted.org>


Change by Kubilay Kocak <koobs.freebsd at gmail.com>:


----------
assignee: docs at python -> 
components:  -2to3 (2.x to 3.x conversion tool), Build, Cross-Build, Documentation, Extension Modules, FreeBSD, Installation, Interpreter Core, Library (Lib), SSL, Tests, Unicode, ctypes
nosy:  -docs at python, koobs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24666>
_______________________________________

From report at bugs.python.org  Tue Jan 28 05:59:50 2020
From: report at bugs.python.org (Kubilay Kocak)
Date: Tue, 28 Jan 2020 10:59:50 +0000
Subject: [issue24666] Buffered I/O does not take file position into account
 when reading blocks
In-Reply-To: <1437282046.06.0.196054163473.issue24666@psf.upfronthosting.co.za>
Message-ID: <1580209190.19.0.654401965026.issue24666@roundup.psfhosted.org>


Change by Kubilay Kocak <koobs.freebsd at gmail.com>:


----------
nosy:  -Alex.Willmer, ezio.melotti, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24666>
_______________________________________

From report at bugs.python.org  Tue Jan 28 07:01:38 2020
From: report at bugs.python.org (Sushma)
Date: Tue, 28 Jan 2020 12:01:38 +0000
Subject: [issue39476] Not convinced with the dynamic data type assignment
Message-ID: <1580212898.77.0.322385429118.issue39476@roundup.psfhosted.org>


New submission from Sushma <sush0907 at gmail.com>:

Hi 

Please find below example and the compiler error,

when i'm assigning value dynamically and when we comparing in "if" loop it is throwing compiler error. It should not throw error it should assign and act as int why it is thinking as string.
Code Snippet:
print("Hello World")

num = input("Enter number ")

print(num)

if(num%3 == 0):
    num+=num
    print(num)

Output in Console:
Hello World
Enter number 15
15
Traceback (most recent call last):
    File "main.py", line 15, in <module>
       if(num%3 == 0):
TypeError: not all arguments converted during string formatting

----------
messages: 360865
nosy: Sush0907
priority: normal
severity: normal
status: open
title: Not convinced with the dynamic data type assignment
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39476>
_______________________________________

From report at bugs.python.org  Tue Jan 28 07:26:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 12:26:16 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580214376.86.0.720588042851.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I tried but failed to reproduce the issue on Fedora Rawhide x86-64. I built Python from source and run Python from its source tree:

./python -m test -v test_zipfile

Maybe the issue only occurs if Python is installed? Or it depends on the filesystem where the ZIP file is created?

On my Fedora 31, /tmp is mounted as a tmpfs filesystem. Using it explicitly doesn't make the test to fail:

./python -m test -v test_zipfile -m test_add_file_after_2107 --tempdir /tmp

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 07:32:21 2020
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 28 Jan 2020 12:32:21 +0000
Subject: [issue39472] IDLE: improve handling of int entry in settings dialog
In-Reply-To: <1580168099.75.0.367298873438.issue39472@roundup.psfhosted.org>
Message-ID: <1580214741.14.0.146044557616.issue39472@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

With keeping it a StringVar, there is an issue where it writes a blank (ie, bad data) to the config file.  Steps to reproduce:

- Go into config dialog and click 'General' tab.
- Delete value from 'Auto squeeze min line'
- Click apply or OK.  A warning message appears in the terminal 
   Warning: config.py - IdleConf.GetOption -
   invalid 'int' value for configuration option 'auto-squeeze-min-lines'
   from section 'PyShell': ''
- Close out of IDLE.
- Start IDLE again - the warning reappears, but on the General tab, it shows the original value.

The issue here is that the custom config-main.cfg is being written to (and then read back in) with the blank.

I picked the auto-squeezer because it has validation on it - `validatecommand=self.digits_only`.

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39472>
_______________________________________

From report at bugs.python.org  Tue Jan 28 07:47:27 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 28 Jan 2020 12:47:27 +0000
Subject: [issue36350] inspect.Signature.parameters and
 inspect.BoundArguments.arguments should be dicts instead of OrderedDicts
In-Reply-To: <1552922208.92.0.691129185173.issue36350@roundup.psfhosted.org>
Message-ID: <1580215647.91.0.390969038162.issue36350@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy:  -inada.naoki
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36350>
_______________________________________

From report at bugs.python.org  Tue Jan 28 07:47:22 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 28 Jan 2020 12:47:22 +0000
Subject: [issue36350] inspect.Signature.parameters and
 inspect.BoundArguments.arguments should be dicts instead of OrderedDicts
In-Reply-To: <1552922208.92.0.691129185173.issue36350@roundup.psfhosted.org>
Message-ID: <1580215642.3.0.0436805699649.issue36350@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 2cca8efe46935c39c445f585bce54954fad2485b by Inada Naoki (R?mi Lapeyre) in branch 'master':
bpo-36350: inspect: Replace OrderedDict with dict. (GH-12412)
https://github.com/python/cpython/commit/2cca8efe46935c39c445f585bce54954fad2485b


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36350>
_______________________________________

From report at bugs.python.org  Tue Jan 28 07:53:36 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 28 Jan 2020 12:53:36 +0000
Subject: [issue38960] DTrace FreeBSD build fix
In-Reply-To: <1575439788.6.0.75374191254.issue38960@roundup.psfhosted.org>
Message-ID: <1580216016.16.0.520016146489.issue38960@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset aabdeb766b7fa581e7de01f3c953b12792f0736d by Petr Viktorin (David Carlier) in branch 'master':
bpo-38960: DTrace build fix for FreeBSD. (GH-17451)
https://github.com/python/cpython/commit/aabdeb766b7fa581e7de01f3c953b12792f0736d


----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38960>
_______________________________________

From report at bugs.python.org  Tue Jan 28 07:47:27 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 28 Jan 2020 12:47:27 +0000
Subject: [issue36350] inspect.Signature.parameters and
 inspect.BoundArguments.arguments should be dicts instead of OrderedDicts
In-Reply-To: <1552922208.92.0.691129185173.issue36350@roundup.psfhosted.org>
Message-ID: <1580215647.91.0.390969038162.issue36350@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy:  -inada.naoki
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36350>
_______________________________________

From report at bugs.python.org  Tue Jan 28 07:47:22 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 28 Jan 2020 12:47:22 +0000
Subject: [issue36350] inspect.Signature.parameters and
 inspect.BoundArguments.arguments should be dicts instead of OrderedDicts
In-Reply-To: <1552922208.92.0.691129185173.issue36350@roundup.psfhosted.org>
Message-ID: <1580215642.3.0.0436805699649.issue36350@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 2cca8efe46935c39c445f585bce54954fad2485b by Inada Naoki (R?mi Lapeyre) in branch 'master':
bpo-36350: inspect: Replace OrderedDict with dict. (GH-12412)
https://github.com/python/cpython/commit/2cca8efe46935c39c445f585bce54954fad2485b


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36350>
_______________________________________

From report at bugs.python.org  Tue Jan 28 08:00:44 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 28 Jan 2020 13:00:44 +0000
Subject: [issue39476] Not convinced with the dynamic data type assignment
In-Reply-To: <1580212898.77.0.322385429118.issue39476@roundup.psfhosted.org>
Message-ID: <1580216444.11.0.107613114436.issue39476@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

The "num" variable is not a number, it *is* a string. Just because you call it "num" doesn't magically turn it into a number. The `input` function returns a string.

You might be thinking of Python 2.7 where `input` automatically evaluated the string as Python code. Python 3 does not do that. If you want to convert the string result of `input` to be a float or an int or some other type, you need to call the `float` or `int` functions.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39476>
_______________________________________

From report at bugs.python.org  Tue Jan 28 08:04:26 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 28 Jan 2020 13:04:26 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580216666.44.0.907630934478.issue39468@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Reporting a better error message than just "Unknown error -1" is a good idea. Stating "an error occurred..." is hardly any better.

The correct error is, I think, "permission denied". Trying to diagnose the *specific* issue (read-only file? file owned by another user? read-only file system? samba permissions? etc) is probably a waste of time. The human reading the error can do that.

Having Python automatically run chattr -i is a bad design. If I've made the history file immutable, it is because I want it to be immutable, not because I want random applications to try to sneakily make it mutable again. Python's role in this should end when it reports that it doesn't have write permission to the file.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Tue Jan 28 08:04:56 2020
From: report at bugs.python.org (=?utf-8?b?VG9tw6HFoSBKZXppb3Jza8O9?=)
Date: Tue, 28 Jan 2020 13:04:56 +0000
Subject: [issue39477] multiprocessing Pool maxtasksperchild=0 raises exception
 with endless traceback
Message-ID: <1580216696.5.0.546840504905.issue39477@roundup.psfhosted.org>


New submission from Tom?? Jeziorsk? <Galileo.Galilei at seznam.cz>:

The following code is expected to fail:


import multiprocessing

def f(x):
	return x

if __name__ == '__main__':
	with multiprocessing.Pool(2, maxtasksperchild=0) as pool:
		pool.map(f, range(3))


since it uses a wrong value of the 'maxtasksperchild' parameter. I expect it to raise a ValueError but instead it starts to fill the stderr with practically endless traceback:


Process ForkPoolWorker-2:
Process ForkPoolWorker-1:
Traceback (most recent call last):
  File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 95, in worker
    assert maxtasks is None or (type(maxtasks) == int and maxtasks > 0)
Traceback (most recent call last):
AssertionError
  File "/usr/lib/python3.6/multiprocessing/process.py", line 258, in _bootstrap
    self.run()
  File "/usr/lib/python3.6/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.6/multiprocessing/pool.py", line 95, in worker
    assert maxtasks is None or (type(maxtasks) == int and maxtasks > 0)
AssertionError
Process ForkPoolWorker-4:
Process ForkPoolWorker-3:
...


I don't think this is expected behavior.
Tested with Python 3.6.9 on Ubuntu 18.04.3.

----------
messages: 360872
nosy: jeyekomon
priority: normal
severity: normal
status: open
title: multiprocessing Pool maxtasksperchild=0 raises exception with endless traceback
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39477>
_______________________________________

From report at bugs.python.org  Tue Jan 28 08:28:13 2020
From: report at bugs.python.org (Ananthakrishnan A S)
Date: Tue, 28 Jan 2020 13:28:13 +0000
Subject: [issue39478] can we add a median function
Message-ID: <1580218093.29.0.978454951198.issue39478@roundup.psfhosted.org>


New submission from Ananthakrishnan A S <ananthakrishnan15.2001 at gmail.com>:

add a function called 'median' that we can use like:

list=[1,2,3,4,5,6,7,8,9]     # declaring list

median(list)      #returns 5

----------
components: Library (Lib)
messages: 360873
nosy: Ananthakrishnan A S
priority: normal
severity: normal
status: open
title: can we add a median function
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39478>
_______________________________________

From report at bugs.python.org  Tue Jan 28 08:33:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 13:33:09 +0000
Subject: [issue39478] can we add a median function
In-Reply-To: <1580218093.29.0.978454951198.issue39478@roundup.psfhosted.org>
Message-ID: <1580218389.86.0.465554607153.issue39478@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It already exists since Python 3.4:
https://docs.python.org/dev/library/statistics.html#statistics.median

Enjoy!

----------
nosy: +vstinner
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39478>
_______________________________________

From report at bugs.python.org  Tue Jan 28 08:48:42 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 28 Jan 2020 13:48:42 +0000
Subject: [issue39477] multiprocessing Pool maxtasksperchild=0 raises exception
 with endless traceback
In-Reply-To: <1580216696.5.0.546840504905.issue39477@roundup.psfhosted.org>
Message-ID: <1580219322.68.0.710243418266.issue39477@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39477>
_______________________________________

From report at bugs.python.org  Tue Jan 28 08:52:43 2020
From: report at bugs.python.org (Ananthakrishnan A S)
Date: Tue, 28 Jan 2020 13:52:43 +0000
Subject: [issue39479] can we add a lcm and gcd function.
Message-ID: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>


New submission from Ananthakrishnan A S <ananthakrishnan15.2001 at gmail.com>:

can we add an lcm and gcd function that can work as:

lcm(4,6) # returns 12

gcd(4,6) # returns 2

----------
components: Library (Lib)
messages: 360875
nosy: Ananthakrishnan A S
priority: normal
severity: normal
status: open
title: can we add a lcm and gcd function.
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Jan 28 09:06:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 14:06:06 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580220366.76.0.78550125405.issue39479@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

There is math.gcd():
https://docs.python.org/dev/library/math.html#math.gcd

You can use numpy.lcm():
https://docs.scipy.org/doc/numpy-1.15.0/reference/generated/numpy.lcm.html

Is it common to need lcm()? Do you have examples of applications which need lcm()? It's trivial to implement lcm():
https://stackoverflow.com/questions/51716916/built-in-module-to-calculate-least-common-multiple

I suggest to reject this feature request, since I never needed lcm() in 10 years of Python, whereas I use gcd() time to time.

----------
nosy: +lemburg, mark.dickinson, rhettinger, stutzbach, vstinner
title: can we add a lcm and gcd function. -> [RFE] Add math.lcm() function: Least Common Multiple
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Jan 28 09:26:11 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 28 Jan 2020 14:26:11 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580221571.52.0.695755214424.issue39479@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Uses for lcm are common enough that it is provided by Excel and the C++ boost. You can use it for working out problems like:

- if event A happens every 14 days, and event B happens every 6 days, then A and B will occur together even lcm(14, 6) days.


By the way, the "trivial" implementation given in the Stackoverflow link has a bug: if both arguments are zero, it raises instead of returning zero.

I wish that gcd took an arbitrary number of arguments, I often need to find the gcd of three or more numbers, and this is a pain:

    gcd(a, gcd(b, gcd(c, gcd(d, e)))))

when I could just say gcd(a, b, c, d, e) and have it work. Likewise of lcm. (For that matter, the gcd of a single number a is just a.)

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Jan 28 09:28:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 14:28:05 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580221685.06.0.412089516398.issue39479@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Jan 28 09:29:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 14:29:18 +0000
Subject: [issue39245] Public API for Vectorcall (PEP 590)
In-Reply-To: <1578400570.24.0.962646656542.issue39245@roundup.psfhosted.org>
Message-ID: <1580221758.89.0.596182024427.issue39245@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I put the priority on release blocker to ensure that we don't miss Python 3.9 deadline. It would be great to not miss 3.9 release.

----------
nosy: +vstinner
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39245>
_______________________________________

From report at bugs.python.org  Tue Jan 28 10:06:26 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jan 2020 15:06:26 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580223986.81.0.156294374519.issue39479@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

reduce(gcd, [a, b, c, d, e])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Jan 28 10:12:19 2020
From: report at bugs.python.org (Ananthakrishnan A S)
Date: Tue, 28 Jan 2020 15:12:19 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580224339.07.0.821684101506.issue39479@roundup.psfhosted.org>


Ananthakrishnan A S <ananthakrishnan15.2001 at gmail.com> added the comment:

I created this issue as i came across the following question:

There are n students in class A,and m students in class B.each class divides into teams for a competition.What is the biggest possible team size that can be divided,such that  each team has same number of members.

We can solve this type of problems easily if we have lcm() in math library.And there are lots of real life applications where we have to use lcm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Jan 28 10:38:05 2020
From: report at bugs.python.org (Marcel Plch)
Date: Tue, 28 Jan 2020 15:38:05 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580225885.42.0.0587220931557.issue39460@roundup.psfhosted.org>


Marcel Plch <mplch at redhat.com> added the comment:

Is currently anybody actively working on this? Please, report what you have found out, if so.
I'd like to start digging into this tomorrow and possibly avoid any duplicit work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 11:33:36 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 28 Jan 2020 16:33:36 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580229216.36.0.973917452797.issue39401@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> For clarity, I'm removing 3.9 from the affected versions. This version 
> does not support Windows 7, and only Windows 7 is vulnerable to this
> DLL hijack.

I added 3.9 for the related issue to switch to using a static import, since Windows 7 isn't supported in 3.9. But I guess that should have been made a separate issue, or added to the omnibus issue bpo-32592.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Tue Jan 28 12:07:14 2020
From: report at bugs.python.org (Ian Jackson)
Date: Tue, 28 Jan 2020 17:07:14 +0000
Subject: [issue39480] referendum reference is needlessly annoying
Message-ID: <1580231234.47.0.658599858582.issue39480@roundup.psfhosted.org>


New submission from Ian Jackson <dlgruj at fyvzl.net>:

The section "Fancier Output Formatting" has the example below.  This will remind many UK readers of the 2016 EU referendum.  About half of those readers will be quite annoyed.

This annoyance seems entirely avoidable; a different example which did not refer to politics would demonstrate the behaviour just as well.

Changing this example would (in the words of the CoC) also show more empathy, and be more considerate towards, python contributors unhappy with recent political developments in the UK, without having to make anyone else upset in turn.

  >>> year = 2016
  >>> event = 'Referendum'
  >>> f'Results of the {year} {event}'
  'Results of the 2016 Referendum'

  >>> yes_votes = 42_572_654
  >>> no_votes = 43_132_495
  >>> percentage = yes_votes / (yes_votes + no_votes)
  >>> '{:-9} YES votes  {:2.2%}'.format(yes_votes, percentage)' 42572654 YES votes  49.67%'

----------
assignee: docs at python
components: Documentation
messages: 360883
nosy: diziet, docs at python
priority: normal
severity: normal
status: open
title: referendum reference is needlessly annoying
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39480>
_______________________________________

From report at bugs.python.org  Tue Jan 28 12:08:17 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 28 Jan 2020 17:08:17 +0000
Subject: [issue39440] Use PyNumber_InPlaceAdd in sum() for the second
 iteration onward
In-Reply-To: <1579820412.98.0.670054717235.issue39440@roundup.psfhosted.org>
Message-ID: <1580231297.47.0.373459893924.issue39440@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +17619
pull_request: https://github.com/python/cpython/pull/18240

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39440>
_______________________________________

From report at bugs.python.org  Tue Jan 28 12:08:51 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 28 Jan 2020 17:08:51 +0000
Subject: [issue39440] Use PyNumber_InPlaceAdd in sum() for the second
 iteration onward
In-Reply-To: <1579820412.98.0.670054717235.issue39440@roundup.psfhosted.org>
Message-ID: <1580231331.12.0.508767542846.issue39440@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Perhaps. I've opened a PR to update the comment with more info.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39440>
_______________________________________

From report at bugs.python.org  Tue Jan 28 12:17:00 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jan 2020 17:17:00 +0000
Subject: [issue39480] referendum reference is needlessly annoying
In-Reply-To: <1580231234.47.0.658599858582.issue39480@roundup.psfhosted.org>
Message-ID: <1580231820.44.0.339980092542.issue39480@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39480>
_______________________________________

From report at bugs.python.org  Tue Jan 28 12:16:57 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Jan 2020 17:16:57 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
Message-ID: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

See PEP 585, which is still under review and may change in response to this work.

https://www.python.org/dev/peps/pep-0585/

----------
components: Interpreter Core
messages: 360885
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Implement PEP 585 (Type Hinting Generics In Standard Collections)
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Jan 28 12:17:26 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 28 Jan 2020 17:17:26 +0000
Subject: [issue39481] Implement PEP 585 (Type Hinting Generics In Standard
 Collections)
In-Reply-To: <1580231817.93.0.47144630055.issue39481@roundup.psfhosted.org>
Message-ID: <1580231846.7.0.434772671373.issue39481@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
keywords: +patch
pull_requests: +17620
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18239

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39481>
_______________________________________

From report at bugs.python.org  Tue Jan 28 12:41:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 17:41:47 +0000
Subject: [issue39401] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580233307.36.0.202995664199.issue39401@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:12:33 2020
From: report at bugs.python.org (Fred Drake)
Date: Tue, 28 Jan 2020 18:12:33 +0000
Subject: [issue39480] referendum reference is needlessly annoying
In-Reply-To: <1580231234.47.0.658599858582.issue39480@roundup.psfhosted.org>
Message-ID: <1580235153.68.0.640121927868.issue39480@roundup.psfhosted.org>


Change by Fred Drake <fdrake at gmail.com>:


----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39480>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:27:56 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Jan 2020 18:27:56 +0000
Subject: [issue39469] Support for relative home path in pyvenv.cfg
In-Reply-To: <1580158688.69.0.521881077968.issue39469@roundup.psfhosted.org>
Message-ID: <1580236076.96.0.281019160279.issue39469@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Do note that virtual environments are not designed to be portable in general, so this would be a fundamental change in the design and purpose of virtual environments.

----------
nosy: +brett.cannon, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39469>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:32:16 2020
From: report at bugs.python.org (Jeff Edwards)
Date: Tue, 28 Jan 2020 18:32:16 +0000
Subject: [issue39469] Support for relative home path in pyvenv.cfg
In-Reply-To: <1580236076.96.0.281019160279.issue39469@roundup.psfhosted.org>
Message-ID: <CAEWphW1=Oe=3gi_Z8qjVRco+LnXfmcB1bAw8U0Ca3fXUVc-baw@mail.gmail.com>


Jeff Edwards <jeff at edwardsj.com> added the comment:

I would say they?re not designed to be, but the also aren?t designed to not
be portable.  This is often useful where open network access isn?t
reasonable, so access to Pip/pipx/pipenv is limited at best.

Suffice to say, is there a significant reason to not allow it?

On Tue, Jan 28, 2020 at 10:28 AM Brett Cannon <report at bugs.python.org>
wrote:

>
> Brett Cannon <brett at python.org> added the comment:
>
> Do note that virtual environments are not designed to be portable in
> general, so this would be a fundamental change in the design and purpose of
> virtual environments.
>
> ----------
> nosy: +brett.cannon, vinay.sajip
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39469>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39469>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:34:31 2020
From: report at bugs.python.org (Ananthakrishnan A S)
Date: Tue, 28 Jan 2020 18:34:31 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580236471.95.0.350332010451.issue39479@roundup.psfhosted.org>


Ananthakrishnan A S <ananthakrishnan15.2001 at gmail.com> added the comment:

Should i proceed with adding a pull request for adding a 'lcm' function in python's math module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:34:57 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 28 Jan 2020 18:34:57 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580236497.55.0.831445725763.issue39468@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

This issue is due to a bug in GNU Readline (actually GNU History). It's documented that write_history [1] returns an errno value. But the internal history_do_write [2] function in this case returns the value from a rename() system call, via the value from histfile_restore [3]. rename() returns -1 on failure, which is being mishandled here as an errno value.

Actually, write permission to the original history file isn't required. GNU History writes to a temp file and then replaces the original via rename(). Normally this just requires write access to the directory. But if the directory or target file has the immutable file attribute set, then rename() fails with errno set to EPERM (at least in Linux; maybe it's a different error in BSD or macOS).

If not for the GNU History bug, this failed call would raise a PermissionError, which is already handled. Maybe it could also write an error message to stderr that write_history failed. For example:

            def write_history():
                try:
                    readline.write_history_file(history)
                except OSError as e:
                    # bpo-19891: home directory does not exist or is not
                    # writable
                    if not (isinstance(e, (FileNotFoundError, PermissionError))
                    # bpo-39468: GNU History may return -1 as an errno value
                            or e.errno == -1):
                        raise
                    print('write_history failed: {!r}'.format(history),
                        file=sys.stderr)

I agree with Steven that the handler should not presume to modify file permissions or attributes.

[1] https://tiswww.case.edu/php/chet/readline/history.html#IDX29
[2] http://git.savannah.gnu.org/cgit/readline.git/tree/histfile.c#n630
[3] http://git.savannah.gnu.org/cgit/readline.git/tree/histfile.c#n458

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:35:53 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Jan 2020 18:35:53 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580236553.49.0.5425346537.issue39461@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> but now it's too change to change it again :-)

I actually don't think it is if we want to revert this. We can raise a deprecation warning if the call to os.fsencode() leads to a value different than its argument and say that people are expected to handle conversions themselves.

> The idea behind PEP 519 was to alleviate str(path_obj) calls between the os/program interface

... where file paths were explicitly expected. os.environ is not a place where file paths are explicitly expected, just a place where they _might_ end up. Basically I only consider PEP 519 valid in places where file paths are the only thing that are expected (e.g. all the path manipulation functions in os.path). Everywhere else where paths are only a "maybe" I would say it shouldn't be relied upon to do implicit conversions.

> Out of curiosity, any idea how often non-strings are used to set os.environ, and so need explicit conversion?

I have anecdotal evidence from outside of Python that people will do this when they can and then are surprised when the conversion doesn't work the way they expect (e.g. floats).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:37:03 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Jan 2020 18:37:03 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580236623.24.0.595032005283.issue39459@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Did the Windows-equivalent project files also get updated?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:38:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 18:38:43 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580236723.48.0.175635186624.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Is currently anybody actively working on this? Please, report what you have found out, if so. I'd like to start digging into this tomorrow and possibly avoid any duplicit work.

I tried but failed to reproduce the bug on Fedora 31 and Fedora Rawhide.

I tested 3.8 and master development branches on Fedora 31 x86-64 laptop: "./configure --with-pydebug CFLAGS=-O0 && make && ./python -m test -v test_zipfile" pass.

I tested Python 3.9.0a3 on my up-to-date Fedora Rawhide x86-64 VM: "./configure --with-pydebug CFLAGS=-O0 && make && ./python -m test -v test_zipfile" pass. I also tried to install Python in /opt/py39 and run tests using /opt/py39/bin/python3.9: the test still pass.

I also tested Python 3.9.0a3 on an up-to-date Fedora Rawhide ppc64 mock container: Python configured as the Fedora package does (LTO, PGO, CFLAGS, LDFLAGS, etc.). test_zipfile pass as well.

Since I cannot reproduce the issue, nor access a machine which the bug occurs, I don't know how to debug this issue.

Can I get access to "s390x Fedora Rawhide 3.x" buildbot worker?

I didn't try to rebuild Python using the Fedora specfile. I only built Python manually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:39:06 2020
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 28 Jan 2020 18:39:06 +0000
Subject: [issue39469] Support for relative home path in pyvenv.cfg
In-Reply-To: <1580158688.69.0.521881077968.issue39469@roundup.psfhosted.org>
Message-ID: <1580236746.19.0.265501080961.issue39469@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

> Suffice to say, is there a significant reason to not allow it?

We have to support that use-case forever. ;) In all seriousness, relative paths get tricky when you forget to resolve the path as appropriate (and in a way that people expect) and it requires making sure that this will work for the next 30 years, so it's not a small thing to take on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39469>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:44:56 2020
From: report at bugs.python.org (Antony Lee)
Date: Tue, 28 Jan 2020 18:44:56 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580237096.22.0.898911212936.issue39461@roundup.psfhosted.org>


Antony Lee <anntzer.lee at gmail.com> added the comment:

FWIW, I'm actually fine with not supporting Path objects in os.environ, as long as the behavior is *consistent* with the env kwarg to subprocess.run() -- note that the original title of the thread only pointed out to the inconsistency, and did not strongly request that os.environ support Paths.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:47:03 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Tue, 28 Jan 2020 18:47:03 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580237223.96.0.0625503655848.issue39479@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I must say that the problem (with two classes divided into teams) seems to me to be exactly one that can be solved with gcd, and lcm itself is mostly useless for it.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:52:17 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 28 Jan 2020 18:52:17 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580237537.27.0.0929879985624.issue39459@roundup.psfhosted.org>


Change by Dino Viehland <dinoviehland at gmail.com>:


----------
pull_requests: +17621
pull_request: https://github.com/python/cpython/pull/18241

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:55:41 2020
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 28 Jan 2020 18:55:41 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580237741.29.0.384996828455.issue39460@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

$ ./python -m test tet_zipfile
0:00:00 load avg: 0.03 Run tests sequentially
0:00:00 load avg: 0.03 [1/1] tet_zipfile
test tet_zipfile crashed -- Traceback (most recent call last):
  File "/home/dje/src/cpython/Lib/test/libregrtest/runtest.py", line 270, in _runtest_inner
    refleak = _runtest_inner2(ns, test_name)
  File "/home/dje/src/cpython/Lib/test/libregrtest/runtest.py", line 221, in _runtest_inner2
    the_module = importlib.import_module(abstest)
  File "/home/dje/src/cpython/Lib/importlib/__init__.py", line 127, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 1021, in _gcd_import
  File "<frozen importlib._bootstrap>", line 998, in _find_and_load
  File "<frozen importlib._bootstrap>", line 975, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'test.tet_zipfile'

tet_zipfile failed

== Tests result: FAILURE ==

1 test failed:
    tet_zipfile

Total duration: 76 ms
Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 13:57:39 2020
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 28 Jan 2020 18:57:39 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580237859.23.0.973862002509.issue39460@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

Sorry, posted the wrong output above.

$ ./python -m test test_zipfile
0:00:00 load avg: 0.01 Run tests sequentially
0:00:00 load avg: 0.01 [1/1] test_zipfile
test test_zipfile failed -- Traceback (most recent call last):
  File "/home/dje/src/cpython/Lib/test/test_zipfile.py", line 620, in test_add_file_after_2107
    self.assertRaises(struct.error, zipfp.write, TESTFN)
AssertionError: error not raised by write

test_zipfile failed in 55.6 sec

== Tests result: FAILURE ==

1 test failed:
    test_zipfile

Total duration: 55.6 sec
Tests result: FAILURE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 14:00:46 2020
From: report at bugs.python.org (Ananthakrishnan A S)
Date: Tue, 28 Jan 2020 19:00:46 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580238046.68.0.280345223363.issue39479@roundup.psfhosted.org>


Ananthakrishnan A S <ananthakrishnan15.2001 at gmail.com> added the comment:

some problems that needs lcm function:

1:find the least number which when divided by 'a','b','c','d' leaves remainder 'e' in each case.

2:person A exercises every 'n' days and person B every 'm' days. A and B both exercised today. How many days will it be until they exercise together again?

3:The LCM is important when adding fractions which have different denominators



we have to use the lcm function when,

1) an event that is or will be repeating over and over.
2) To purchase or get multiple items in order to have enough.
3) To figure out when something will happen again at the same time.

All these shows lcm function should be included in the math library.

So can i proceed with adding pull request to add lcm function in python's math module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Jan 28 14:20:40 2020
From: report at bugs.python.org (David Filiatrault)
Date: Tue, 28 Jan 2020 19:20:40 +0000
Subject: [issue25702] Link Time Optimizations support for GCC and CLANG
In-Reply-To: <1448269180.86.0.895879966461.issue25702@psf.upfronthosting.co.za>
Message-ID: <1580239240.41.0.956357654316.issue25702@roundup.psfhosted.org>


Change by David Filiatrault <david.filiatrault at gmail.com>:


----------
nosy: +David Filiatrault

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25702>
_______________________________________

From report at bugs.python.org  Tue Jan 28 14:21:11 2020
From: report at bugs.python.org (David Filiatrault)
Date: Tue, 28 Jan 2020 19:21:11 +0000
Subject: [issue38980] Compile libpython with -fno-semantic-interposition
In-Reply-To: <1575561631.45.0.417730594345.issue38980@roundup.psfhosted.org>
Message-ID: <1580239271.05.0.946044282472.issue38980@roundup.psfhosted.org>


Change by David Filiatrault <david.filiatrault at gmail.com>:


----------
nosy: +David Filiatrault

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38980>
_______________________________________

From report at bugs.python.org  Tue Jan 28 14:33:19 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 28 Jan 2020 19:33:19 +0000
Subject: [issue39476] Not convinced with the dynamic data type assignment
In-Reply-To: <1580212898.77.0.322385429118.issue39476@roundup.psfhosted.org>
Message-ID: <1580239999.23.0.800186527281.issue39476@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Sushma, asking about the exception message on python-list was the right thing to do.  You should have waited for the answers you got there.  At this point, bugs in basic python operations are extremely rare.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39476>
_______________________________________

From report at bugs.python.org  Tue Jan 28 14:46:57 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jan 2020 19:46:57 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580240817.77.0.693759732006.issue39479@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-1 Given that we had gcd(), I don't see any value to adding *lcm()* as well. 
 
Once you have gcd(), getting the least common multiple is trivial.

Also, it is rare to ever need a lcm() function.  I don't think I've ever seen it in real code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Jan 28 16:19:03 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 28 Jan 2020 21:19:03 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580246343.3.0.323639644477.issue39461@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> as long as the behavior is *consistent* with the env kwarg to 
> subprocess.run() 

subprocess isn't consistent with itself across platforms. The env parameter in Windows is strictly an str->str mapping, like os.environ. This is coded in getenvironment in Modules/_winapi.c:

    if (! PyUnicode_Check(key) || ! PyUnicode_Check(value)) {
        PyErr_SetString(PyExc_TypeError,
            "environment can only contain strings");
        goto error;
    }

At a lower level, should the env parameter of os.spawnve and os.execve  allow path-like objects? Should (Unix) os.putenv allow the name and value to be path-like?

Currently these cases use PyUnicode_FSConverter and PyUnicode_FSDecoder, which support __fspath__ via PyOS_FSPath. PyUnicode_FSDecoder also supports the buffer protocol, with a warning. 

Since we have cases like this where the filesystem encoding is used for string data that's not actually a file path, should alternate ParseTuple converters be added that are limited to just str and bytes? Maybe name them PyUnicode_FSStringEncoder and PyUnicode_FSStringDecoder, where "String" emphasizes that fspath and buffer objects are not allowed. For example:

    int
    PyUnicode_FSStringEncoder(PyObject *path, void *addr)
    {
        PyObject *output = NULL;

        if (path == NULL) {
            Py_DECREF(*(PyObject **)addr);
            *(PyObject **)addr = NULL;
            return 1;
        }

        if (PyBytes_Check(path)) {
            output = path;
            Py_INCREF(output);
        }
        else if (PyUnicode_Check(path)) {
            output = PyUnicode_EncodeFSDefault(path);
            if (!output)
                return 0;
        }
        else {
            PyErr_Format(PyExc_TypeError, "path should be str or bytes, not "
                "%.200s", _PyType_Name(Py_TYPE(path)));
            return 0;
        }

        if ((size_t)PyBytes_GET_SIZE(output) !=
                strlen(PyBytes_AS_STRING(output)))
        {
            PyErr_SetString(PyExc_ValueError, "embedded null byte");
            Py_DECREF(output);
            return 0;
        }
        
        *(PyObject **)addr = output;
        return Py_CLEANUP_SUPPORTED;
    }


    int
    PyUnicode_FSStringDecoder(PyObject *path, void *addr)
    {
        PyObject *output = NULL;

        if (arg == NULL) {
            Py_DECREF(*(PyObject **)addr);
            *(PyObject **)addr = NULL;
            return 1;
        }

        if (PyUnicode_Check(path)) {
            output = path;
            Py_INCREF(output);
        }
        else if (PyBytes_Check(path)) {
            output = PyUnicode_DecodeFSDefaultAndSize(PyBytes_AS_STRING(path),
                        PyBytes_GET_SIZE(path));
            if (!output)
                return 0;
        }
        else {
            PyErr_Format(PyExc_TypeError, "path should be str or bytes, not "
                "%.200s", _PyType_Name(Py_TYPE(path)));
            return 0;
        }
        
        if (PyUnicode_READY(output) == -1) {
            Py_DECREF(output);
            return 0;
        }
        
        if (findchar(PyUnicode_DATA(output), PyUnicode_KIND(output),
                     PyUnicode_GET_LENGTH(output), 0, 1) >= 0) {
            PyErr_SetString(PyExc_ValueError, "embedded null character");
            Py_DECREF(output);
            return 0;
        }
        
        *(PyObject **)addr = output;
        return Py_CLEANUP_SUPPORTED;
    }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Tue Jan 28 16:24:37 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 28 Jan 2020 21:24:37 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580246677.69.0.52770008202.issue39459@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:


New changeset 0cd5bff6b7da3118d0c5a88fc2b80f80eb7c3059 by Dino Viehland in branch 'master':
bpo-39459: include missing test files in windows installer 
https://github.com/python/cpython/commit/0cd5bff6b7da3118d0c5a88fc2b80f80eb7c3059


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Tue Jan 28 16:24:59 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 28 Jan 2020 21:24:59 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580246699.2.0.291484245794.issue39459@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

Nope, thank you for pointing that out.  I've updated them now with PR 18241

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Tue Jan 28 16:30:44 2020
From: report at bugs.python.org (Ernest W. Durbin III)
Date: Tue, 28 Jan 2020 21:30:44 +0000
Subject: [issue37860] Add netlify deploy preview for docs
In-Reply-To: <1565817286.53.0.142673590989.issue37860@roundup.psfhosted.org>
Message-ID: <1580247044.92.0.660063162513.issue37860@roundup.psfhosted.org>


Change by Ernest W. Durbin III <ernest at python.org>:


----------
pull_requests: +17622
pull_request: https://github.com/python/cpython/pull/18242

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37860>
_______________________________________

From report at bugs.python.org  Tue Jan 28 16:57:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 28 Jan 2020 21:57:43 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580248663.92.0.816883950836.issue39459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The Windows installer copies Lib/test/ and subdirectories: see <InstallFiles Include="$(PySourcePath)Lib\test\**\*" ...> in Tools/msi/test/test.wixproj.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Tue Jan 28 17:07:57 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jan 2020 22:07:57 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580249277.26.0.631933010545.issue39461@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't think proposal this makes sense.  os.environ is a dict-like object providing clean access to the environment variables.  Use of Paths is an orthogonal problem unrelated to environment variables.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Tue Jan 28 17:09:23 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 28 Jan 2020 22:09:23 +0000
Subject: [issue39480] referendum reference is needlessly annoying
In-Reply-To: <1580231234.47.0.658599858582.issue39480@roundup.psfhosted.org>
Message-ID: <1580249363.54.0.278724822922.issue39480@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Oh come on now, this is such a trivialisation of the CoC that I cannot believe that it is a good-faith bug report and not a troll. I'm surprised you didn't toss in the words "triggered" and "micro-aggression" while you're at it.

The example has nothing to do with the UK Referendum (or for that matter, the 2016 referendums in Zambia, Columbia, Bolivia, or Italy): the numbers are completely different, the results and percentages are different, and there is no non-arbitrary way to map Yes/No of a made up example to either Leave/Remain or any other actual results. If you want to read the example as a better world where the majority of peole voted "No" to leaving the EU, then go ahead.

Why should you privilege the Brexit referendum over (let's say) the Irish referendum which voted in favour of allowing same-sex marriages? Or are you annoyed by that too?

Any year is going to "annoy" some fraction of the readers:

2019 is the year that the Liberal Party (don't be fooled by the name: they're the authoritarian-right, climate-change-denying reactionary-right party) won the Australian Federal election on a campaign of Facebook fake news, "annoying" almost half the country. It is also the year that President Trump was impeached, annoying half of the USA. 2018 was the year Vladimir Putin was re-elected president of Russia, annoying and *terrifying* some percentage of Russians. 2017 was the year that Trump was sworn in as US President. Shall we go on?

2016 was also the year that Taiwan saw the first ever majority by a non-KMT party, and the first female prime minister, when the Democratic Progressive Party won their elections.

By the way, the fact that I've just spent easily half an hour getting annoyed at this bug report and writing this response disproves your claim about avoiding making others upset.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39480>
_______________________________________

From report at bugs.python.org  Tue Jan 28 17:16:12 2020
From: report at bugs.python.org (Dino Viehland)
Date: Tue, 28 Jan 2020 22:16:12 +0000
Subject: [issue39459] test_import: test_unwritable_module() fails on AMD64
 Fedora Stable Clang Installed 3.x
In-Reply-To: <1580116744.62.0.562593515869.issue39459@roundup.psfhosted.org>
Message-ID: <1580249772.8.0.756592130324.issue39459@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:

I guess the update to lib.pyproj probably just makes the files show up when opening the solution in Visual Studio then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39459>
_______________________________________

From report at bugs.python.org  Tue Jan 28 17:33:48 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 28 Jan 2020 22:33:48 +0000
Subject: [issue39469] Support for relative home path in pyvenv.cfg
In-Reply-To: <1580158688.69.0.521881077968.issue39469@roundup.psfhosted.org>
Message-ID: <1580250828.98.0.597252195615.issue39469@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Suffice to say, is there a significant reason to not allow it?

It's poorly supported by packaging. In particular, relocating an environment isn't supported with entry-point scripts, which pip installs with a fully-qualified shebang. Moreover, entry-point scripts in Windows are created as exe files (e.g. "pip.exe") that embed the fully-qualified path of python[w].exe in the environment, plus a zipped __main__.py. For example, given an environment at "C:\Temp\env", running "C:\Temp\env\Scripts\pip.exe" in turn spawns a child process with the command line: "C:\Temp\env\Scripts\python.exe" "C:\Temp\env\Scripts\pip.exe". This breaks if the environment is renamed or relocated.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39469>
_______________________________________

From report at bugs.python.org  Tue Jan 28 17:52:40 2020
From: report at bugs.python.org (Jeff Edwards)
Date: Tue, 28 Jan 2020 22:52:40 +0000
Subject: [issue39469] Support for relative home path in pyvenv.cfg
In-Reply-To: <1580250828.98.0.597252195615.issue39469@roundup.psfhosted.org>
Message-ID: <CAEWphW2iqgrXa-vhE6=k2c5wWVsud1at4QMwxyfHFGSW66CUDA@mail.gmail.com>


Jeff Edwards <jeff at edwardsj.com> added the comment:

Interesting, I hadn?t realized that it would embed the FQ Executable path,
but that does make sense overall.  I guess I had always planned on fixing
the ?bin? directory anyway afterwards, it?s just that the lack of relative
home made it significantly harder to encapsulate multiple environments
running with the same interpreter without having to do a complete
reinstall, and venv did seem like the best and most-pythonic way to do it.

I?ll think about it a bit more

On Tue, Jan 28, 2020 at 2:33 PM Eryk Sun <report at bugs.python.org> wrote:

>
> Eryk Sun <eryksun at gmail.com> added the comment:
>
> > Suffice to say, is there a significant reason to not allow it?
>
> It's poorly supported by packaging. In particular, relocating an
> environment isn't supported with entry-point scripts, which pip installs
> with a fully-qualified shebang. Moreover, entry-point scripts in Windows
> are created as exe files (e.g. "pip.exe") that embed the fully-qualified
> path of python[w].exe in the environment, plus a zipped __main__.py. For
> example, given an environment at "C:\Temp\env", running
> "C:\Temp\env\Scripts\pip.exe" in turn spawns a child process with the
> command line: "C:\Temp\env\Scripts\python.exe"
> "C:\Temp\env\Scripts\pip.exe". This breaks if the environment is renamed or
> relocated.
>
> ----------
> nosy: +eryksun
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39469>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39469>
_______________________________________

From report at bugs.python.org  Tue Jan 28 18:10:55 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 28 Jan 2020 23:10:55 +0000
Subject: [issue39480] referendum reference is needlessly annoying
In-Reply-To: <1580231234.47.0.658599858582.issue39480@roundup.psfhosted.org>
Message-ID: <1580253055.28.0.407224754365.issue39480@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I concur with Steven.  The association with Brexit is specious and the CoC wasn't intended to apply to second guessing technical examples.

----------
assignee: docs at python -> willingc
nosy: +rhettinger, willingc
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39480>
_______________________________________

From report at bugs.python.org  Tue Jan 28 18:34:33 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 28 Jan 2020 23:34:33 +0000
Subject: [issue34095] [2.7] Seg fault on archlinux 32 when run tests with
 xvfb-run
In-Reply-To: <1531314252.99.0.56676864532.issue34095@psf.upfronthosting.co.za>
Message-ID: <1580254473.63.0.506623873719.issue34095@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

2.7 is dead.

----------
nosy: +benjamin.peterson
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34095>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:09:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 00:09:15 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580256555.44.0.940477156407.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fedora downstream issue: https://bugzilla.redhat.com/show_bug.cgi?id=1795576

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:15:01 2020
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 29 Jan 2020 00:15:01 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() fails on s390x
 Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580256901.96.0.511100823549.issue39460@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

Do you believe that a single GCC 10 issue is affecting PPC64LE, ARM, and s390x, but expressed in different manners on the different architectures OR is the PPC64LE issue separate and architecture-depdendent?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:16:41 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:16:41 +0000
Subject: [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1580257001.78.0.222097609429.issue14787@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14787>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:17:15 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:17:15 +0000
Subject: [issue16027] pkgutil doesn't support frozen modules
In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za>
Message-ID: <1580257035.57.0.142120170197.issue16027@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16027>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:17:35 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 29 Jan 2020 00:17:35 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580257055.69.0.329288652087.issue39460@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

I think this happens "randomly" regardless of the architecture. I've seen it on x86_64 as well.

----------
title: test_zipfile: test_add_file_after_2107() fails on s390x Fedora Rawhide 3.x -> test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:21:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 00:21:33 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580257293.07.0.510260881868.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I suspect that the timestamp set by os.utime() is not the one seen by os.stat(). Or maybe time.localtime() behavior changed.

Try attached utime_stat_localtime.py script.

Output on Fedora 31 in my home directory which uses btrfs:

$ python3.7 utime_stat_localtime.py 
os.utime (sec): 4386268800
os.stat (sec): 4386268800
os.stat (ns): 4386268800000000000
stat==utime? True
localtime: (2108, 12, 30, 1, 0, 0)

----------
Added file: https://bugs.python.org/file48869/utime_stat_localtime.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:26:42 2020
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 29 Jan 2020 00:26:42 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580257602.33.0.420488767684.issue39460@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

Output on s390x Fedora Rawhide:
$ ./python utime_stat_localtime.py 
os.utime (sec): 4386268800
os.stat (sec): 4386268800
os.stat (ns): 2147483647000000000
stat==utime? False
localtime: (2038, 1, 18, 22, 14, 7)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:33:23 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:33:23 +0000
Subject: [issue16826] Don't check for PYTHONCASEOK if interpreter started with
 -E
In-Reply-To: <1356964491.55.0.198222992625.issue16826@psf.upfronthosting.co.za>
Message-ID: <1580258003.93.0.43561143181.issue16826@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

This is still occurring. Probably need to add `and sys.ignore_environment` to https://github.com/python/cpython/blob/0cd5bff6b7da3118d0c5a88fc2b80f80eb7c3059/Lib/importlib/_bootstrap_external.py#L38.

----------
versions: +Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16826>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:34:50 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:34:50 +0000
Subject: [issue16748] Make CPython test package discoverable
In-Reply-To: <1356138147.12.0.530314626781.issue16748@psf.upfronthosting.co.za>
Message-ID: <1580258090.18.0.920452870864.issue16748@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16748>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:36:22 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:36:22 +0000
Subject: [issue16737] Different behaviours in script run directly and via
 runpy.run_module
In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za>
Message-ID: <1580258182.6.0.153878927723.issue16737@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16737>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:36:33 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:36:33 +0000
Subject: [issue16721] configure incorrectly adds -OPT:Olimit=0 for clang
In-Reply-To: <1355868497.91.0.141324882263.issue16721@psf.upfronthosting.co.za>
Message-ID: <1580258193.85.0.833646194873.issue16721@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16721>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:37:07 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:37:07 +0000
Subject: [issue16651] Find out what stdlib modules lack a pure Python
 implementation
In-Reply-To: <1355078393.91.0.564166411172.issue16651@psf.upfronthosting.co.za>
Message-ID: <1580258227.06.0.420790822222.issue16651@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16651>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:38:30 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:38:30 +0000
Subject: [issue16392] import crashes on circular imports in ext modules
In-Reply-To: <1351946554.54.0.101006341814.issue16392@psf.upfronthosting.co.za>
Message-ID: <1580258310.03.0.607488637981.issue16392@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16392>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:38:55 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:38:55 +0000
Subject: [issue16217] Tracebacks are unnecessarily verbose when using 'python
 -m'
In-Reply-To: <1350132701.04.0.542395484982.issue16217@psf.upfronthosting.co.za>
Message-ID: <1580258335.08.0.138390779619.issue16217@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16217>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:39:05 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:39:05 +0000
Subject: [issue16101] Verify all imported modules at startup are needed
In-Reply-To: <1349110028.76.0.413324569089.issue16101@psf.upfronthosting.co.za>
Message-ID: <1580258345.14.0.390171611233.issue16101@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16101>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:39:26 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:39:26 +0000
Subject: [issue15987] Provide a way to compare AST nodes for equality
 recursively
In-Reply-To: <1348166637.22.0.281544835659.issue15987@psf.upfronthosting.co.za>
Message-ID: <1580258366.14.0.95672533987.issue15987@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15987>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:40:10 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:40:10 +0000
Subject: [issue15911] can't step through
 _frozen_importlib/importlib._bootstrap using pdb
In-Reply-To: <1347305436.8.0.778141669429.issue15911@psf.upfronthosting.co.za>
Message-ID: <1580258410.29.0.714221167611.issue15911@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
title: can't step through _frozen_importlib/importlib._bootstrap using gdb -> can't step through _frozen_importlib/importlib._bootstrap using pdb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15911>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:42:31 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:42:31 +0000
Subject: [issue15911] can't step through
 _frozen_importlib/importlib._bootstrap using pdb
In-Reply-To: <1347305436.8.0.778141669429.issue15911@psf.upfronthosting.co.za>
Message-ID: <1580258551.59.0.608398749472.issue15911@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.9 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15911>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:46:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 00:46:41 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580258801.6.0.642531931802.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> os.stat (sec): 4386268800
> ...
> localtime: (2038, 1, 18, 22, 14, 7)

Aha, localtime() behavior changed for timestamp larger than 2**31. What is the version of the glibc package?

> s390x Fedora Rawhide 3.x:
> https://buildbot.python.org/all/#/builders/323/builds/6

pythoninfo of this build says:

platform.libc_ver: glibc 2.30.9000

(Same in the latest build, build 25.)

--

On AMD64 Fedora Rawhide 3.x with glibc-2.30.9000-31.fc32.x86_64, I get years after 2038:

vstinner at python-builder-rawhide$ ./python
Python 3.9.0a3+ (heads/master:0cd5bff6b7, Jan 28 2020, 19:39:07) 
[GCC 10.0.1 20200123 (Red Hat 10.0.1-0.5)] on linux
Type "help", "copyright", "credits" or "license" for more information.

>>> import time
>>> time.localtime(2**31)
time.struct_time(tm_year=2038, tm_mon=1, tm_mday=18, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=0, tm_yday=18, tm_isdst=0)

>>> time.localtime(2**31-3600*24)
time.struct_time(tm_year=2038, tm_mon=1, tm_mday=17, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=6, tm_yday=17, tm_isdst=0)

>>> time.localtime(2**32)
time.struct_time(tm_year=2106, tm_mon=2, tm_mday=7, tm_hour=1, tm_min=28, tm_sec=16, tm_wday=6, tm_yday=38, tm_isdst=0)

>>> time.localtime(2**33)
time.struct_time(tm_year=2242, tm_mon=3, tm_mday=16, tm_hour=8, tm_min=56, tm_sec=32, tm_wday=2, tm_yday=75, tm_isdst=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:46:55 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:46:55 +0000
Subject: [issue15867] make importlib documentation easier to use
In-Reply-To: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za>
Message-ID: <1580258815.84.0.529162534802.issue15867@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15867>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:47:02 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:47:02 +0000
Subject: [issue15693] expose glossary link on hover
In-Reply-To: <1345132108.78.0.567099034623.issue15693@psf.upfronthosting.co.za>
Message-ID: <1580258822.86.0.000689602386764.issue15693@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15693>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:49:19 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:49:19 +0000
Subject: [issue14715] test.support.DirsOnSysPath should be replaced by
 importlib.test.util.import_state
In-Reply-To: <1336079069.84.0.625762752869.issue14715@psf.upfronthosting.co.za>
Message-ID: <1580258959.41.0.386643024539.issue14715@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Do we still care about this, Eric?

----------
versions: +Python 3.9 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14715>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:50:15 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:50:15 +0000
Subject: [issue14678] Update zipimport to support importlib.invalidate_caches()
In-Reply-To: <1335462110.31.0.00575372691618.issue14678@psf.upfronthosting.co.za>
Message-ID: <1580259015.56.0.61701388661.issue14678@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14678>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:51:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 00:51:09 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580259069.46.0.348354330407.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I don't see anything about localtime() or the year 2038 bug in glibc 2.30 release notes:
https://lwn.net/Articles/795127/

I'm aware of work in the Linux kernel and glibc for the year 2038 bug, but for 32-bit systems:
https://lwn.net/Articles/776435/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:54:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 00:54:19 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580259259.39.0.392571393979.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> s390x Fedora Rawhide 3.x:
> https://buildbot.python.org/all/#/builders/323/builds/6

I also checked the configure: time_t size is 64-bit on this system, so it should not be impacted on the glibc/Linux kernel work on the year 2038 bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:55:27 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:55:27 +0000
Subject: [issue14604] spurious stat() calls in importlib
In-Reply-To: <1334663931.89.0.459058246046.issue14604@psf.upfronthosting.co.za>
Message-ID: <1580259327.02.0.113849944116.issue14604@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14604>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:56:39 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:56:39 +0000
Subject: [issue14067] Avoid more stat() calls in importlib
In-Reply-To: <1329772687.53.0.782755770398.issue14067@psf.upfronthosting.co.za>
Message-ID: <1580259399.62.0.732100500921.issue14067@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14067>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:57:17 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:57:17 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>
Message-ID: <1580259437.98.0.616030022289.issue14019@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14019>
_______________________________________

From report at bugs.python.org  Tue Jan 28 19:47:49 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 29 Jan 2020 00:47:49 +0000
Subject: [issue15600] expose the finder details used by the FileFinder path
 hook
In-Reply-To: <1344483800.66.0.152640034936.issue15600@psf.upfronthosting.co.za>
Message-ID: <1580258869.67.0.746403908548.issue15600@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Since Eric never replied I'm just closing this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15600>
_______________________________________

From report at bugs.python.org  Tue Jan 28 20:04:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 01:04:57 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x: time.localtime() limited to year 2038
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580259897.89.0.32716283849.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Notes on the glibc:

* localtime() calls __tz_convert()
* localtime() and __tz_convert() have been modified recently to support 64-bit timestamp
* __tz_convert() is implemented in time/tzset.c
* localtime() is implemented in time/localtime.c

----------
title: test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x -> test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x: time.localtime() limited to year 2038

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 20:21:05 2020
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 29 Jan 2020 01:21:05 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x: time.localtime() limited to year 2038
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580260865.95.0.486767936198.issue39460@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

$ ./python
Python 3.9.0a3+ (heads/master:aabdeb766b, Jan 28 2020, 13:50:48) 
[GCC 10.0.1 20200121 (Red Hat 10.0.1-0.4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.localtime(2**31)
time.struct_time(tm_year=2038, tm_mon=1, tm_mday=18, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=0, tm_yday=18, tm_isdst=0)
>>> time.localtime(2**31-3600*24)
time.struct_time(tm_year=2038, tm_mon=1, tm_mday=17, tm_hour=22, tm_min=14, tm_sec=8, tm_wday=6, tm_yday=17, tm_isdst=0)
>>> time.localtime(2**32)
time.struct_time(tm_year=2106, tm_mon=2, tm_mday=7, tm_hour=1, tm_min=28, tm_sec=16, tm_wday=6, tm_yday=38, tm_isdst=0)
>>> time.localtime(2**33)
time.struct_time(tm_year=2242, tm_mon=3, tm_mday=16, tm_hour=8, tm_min=56, tm_sec=32, tm_wday=2, tm_yday=75, tm_isdst=1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 20:38:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 01:38:37 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x: time.localtime() limited to year 2038
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580261917.4.0.459141445304.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

David Edelsohn:

> Output on s390x Fedora Rawhide:
> (...)
> os.stat (sec): 4386268800
> os.stat (ns): 2147483647000000000

Oh wait, ns != sec * 10**9 here. "2147483647" is 2**31-1 (INT_MAX).

It looks like a bug in fill_time() of Modules/posixmodule.c. I suspect a bug in _PyLong_FromTime_t().

On this buildbot worker, we have:

    checking size of long long... 8
    checking size of time_t... 8

So _PyLong_FromTime_t() should be implemented as:

    return PyLong_FromLongLong((long long)t);

_PyLong_FromTime_t() raw value is exported in os.stat() as os.stat(filename)[8].

Attached utime_stat_localtime2.py exposes it:

vstinner at apu$ ./python utime_stat_localtime2.py 
os.utime (sec): 4386268800
os.stat (sec int): 4386268800
os.stat (sec float): 4386268800.0
os.stat (ns): 4386268800000000000

On Fedora 31 x86-64 with GCC 9.2.1, gcc -O3, _PyLong_FromTime_t() really just calls PyLong_FromLongLong():

(gdb) disassemble _PyLong_FromTime_t
Dump of assembler code for function _PyLong_FromTime_t:
   0x0000000000521f30 <+0>:	jmp    0x457800 <PyLong_FromLongLong>

----------
Added file: https://bugs.python.org/file48870/utime_stat_localtime2.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 20:39:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 01:39:15 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580261955.72.0.1913848002.issue39460@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x: time.localtime() limited to year 2038 -> test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 20:52:12 2020
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 29 Jan 2020 01:52:12 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580262732.36.0.361768247072.issue39460@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

$ ./python utime_stat_localtime2.py 
os.utime (sec): 4386268800
os.stat (sec int): 2147483647
os.stat (sec float): 2147483647.0
os.stat (ns): 2147483647000000000

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 20:55:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 01:55:41 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580262941.67.0.582315729719.issue39461@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I understand that os.fsencode() was modified to support the fspath protocol to be consistent with the C implementation PyUnicode_FSConverter() which calls PyOS_FSPath().

I agree that at least in C, we need two functions: one which accepts (str, bytes), another which also supports the fspath protocol.

IMHO PyUnicode_FSConverter() was modified to support fspath because it was convenient to only modify one function. But this change wasn't designed to decide in each function if fspath should be accepted or not.

For me, os.putenv() should not accept fspath neither.

This issue is not specific to os.environ. It's more general about the PEP 519 implementation. IMHO the implementation should be "adjusted".

I like the deprecation idea ;-) We did something similar with functions accepting float by mistake. First a deprecation warning was emited, and then it became a hard error (exception).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Tue Jan 28 20:56:01 2020
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 29 Jan 2020 01:56:01 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580262961.72.0.755284409996.issue39460@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

Not -O3, but it's calling PyLong_FromLongLong on s390x as well

   0x00000000011ca524 <+28>:	brasl	%r14,0x10649b0 <PyLong_FromLongLong>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 21:01:48 2020
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 29 Jan 2020 02:01:48 +0000
Subject: [issue39461] [RFE] os.environ should support Path-like values,
 like subprocess(..., env=...)
In-Reply-To: <1580120758.52.0.283644207368.issue39461@roundup.psfhosted.org>
Message-ID: <1580263308.37.0.842511107611.issue39461@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Well, I would prefer if Path objects were seamless to use since at one time they were actually strings, but I can live with Brett's rationale that they are only seamless where paths are explicitly expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39461>
_______________________________________

From report at bugs.python.org  Tue Jan 28 21:03:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 02:03:03 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580263383.02.0.560484845748.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

"""
$ ./python utime_stat_localtime2.py 
os.utime (sec): 4386268800
os.stat (sec int): 2147483647
os.stat (sec float): 2147483647.0
os.stat (ns): 2147483647000000000
"""

It doesn't make sense !? In msg360916, you had:

os.stat (sec): 4386268800 <= os.stat().st_mtime
os.stat (ns): 2147483647000000000 <= os.stat().st_mtime._ns

How is it possible that sometimes st_mtime is right, and sometimes st_mtime is so plain wrong?

--

Test setting mtime in Python, reading mtime using /usr/bin/stat, then reading file stat in Python:

$ touch testfn

$ python3 -c 'import os; os.utime("testfn", (4386268800, 4386268800))'

$ stat testfn 
(...)
Modify: 2108-12-30 01:00:00.000000000 +0100
(...)

$ python3 -c 'import os; st=os.stat("testfn"); print(st); print(tuple(st)); print(st.st_mtime_ns)'

os.stat_result(st_mode=33204, st_ino=24648296, st_dev=40, st_nlink=1, st_uid=1000, st_gid=1000, st_size=0, st_atime=4386268800, st_mtime=4386268800, st_ctime=1580263179)
(33204, 24648296, 40, 1, 1000, 1000, 0, 4386268800, 4386268800, 1580263179)
4386268800000000000

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 21:22:04 2020
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 29 Jan 2020 02:22:04 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580264524.23.0.695127229133.issue39460@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

[dje at rawhide ~]$ touch testfn
[dje at rawhide ~]$ python3 -c 'import os; os.utime("testfn", (4386268800, 4386268800))'
[dje at rawhide ~]$ stat testfn
  File: testfn
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Device: fd00h/64768d	Inode: 17887487    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1001/     dje)   Gid: ( 1001/     dje)
Context: unconfined_u:object_r:user_home_t:s0
Access: 2038-01-18 22:14:07.000000000 -0500
Modify: 2038-01-18 22:14:07.000000000 -0500
Change: 2020-01-28 21:19:14.707112199 -0500
 Birth: 2020-01-28 21:19:01.627112199 -0500
[dje at rawhide ~]$ python3 -c 'import os; st=os.stat("testfn"); print(st); print(tuple(st)); print(st.st_mtime_ns)'
os.stat_result(st_mode=33204, st_ino=17887487, st_dev=64768, st_nlink=1, st_uid=1001, st_gid=1001, st_size=0, st_atime=2147483647, st_mtime=2147483647, st_ctime=1580264354)
(33204, 17887487, 64768, 1, 1001, 1001, 0, 2147483647, 2147483647, 1580264354)
2147483647000000000

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 21:27:38 2020
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 29 Jan 2020 02:27:38 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580264858.71.0.0430047442144.issue39460@roundup.psfhosted.org>


David Edelsohn <dje.gcc at gmail.com> added the comment:

In utime_stat_localtime.py, "os.stat (sec)" is the result of os.utime.
In utime_stat_localtime2.py "os.stat (sec int)" is the result of os.stat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Tue Jan 28 21:30:16 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 29 Jan 2020 02:30:16 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580265016.3.0.445861794601.issue39401@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This is now assigned CVE-2020-8315 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8315 https://nvd.nist.gov/vuln/detail/CVE-2020-8315)

Thanks Anthony for the report! I included your name as the reporter, though I don't see it on any of the pages.

----------
title: Unsafe dll loading in getpathp.c on Win7 -> [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Tue Jan 28 21:39:52 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Wed, 29 Jan 2020 02:39:52 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580265592.45.0.411354773931.issue39479@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

I agree with Raymond that it's really seldom needed. However, I'd like to point out that the "trivial" implementation might not be so trivial after all: as Steven said, it mishandles (0,0) case. And even Tim fell into that trap, so it can't be said it's easily avoided. I agree that this case doesn't really appear in "real world" tasks, but that's not really an excuse: imagine a factorial that didn't work for 0.

Also, a bit more often used case: seeing the code for lcm of 2 arguments, people might (and do; I've seen it) generalize to 3 or more arguments in a way that seems logical and is often correct, but not always (a*b*c//gcd(a,b,c)).

And one more tidbit: the usual formula for lcm doesn't really work for the case of fraction inputs. I know that currently math.gcd doesn't handle fractions, but it could. It's imaginable that that feature will some day be added (just like pow recently started supporting modular inverses), and then suddenly lcd implementations will silently give the wrong result for fractions.

A smart man;-) once said that the main criteria for inclusion in stdlib is that the function is often needed by users, _and_ it's often implemented wrong. I think lcm doesn't really satisfy the first criterion, but it does satisfy the second.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Tue Jan 28 21:46:39 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 29 Jan 2020 02:46:39 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580265999.97.0.423516775394.issue39401@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 6a65eba44bfd82ccc8bed4b5c6dd6637549955d5 by Steve Dower in branch 'master':
bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier (GH-18231)
https://github.com/python/cpython/commit/6a65eba44bfd82ccc8bed4b5c6dd6637549955d5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Tue Jan 28 22:22:02 2020
From: report at bugs.python.org (Joseph Gordon)
Date: Wed, 29 Jan 2020 03:22:02 +0000
Subject: [issue14019] Unify tests for str.format and string.Formatter
In-Reply-To: <1329293704.94.0.0580926341423.issue14019@psf.upfronthosting.co.za>
Message-ID: <1580268122.92.0.554101426441.issue14019@roundup.psfhosted.org>


Change by Joseph Gordon <j.gordon.matthew at gmail.com>:


----------
nosy:  -josephgordon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14019>
_______________________________________

From report at bugs.python.org  Tue Jan 28 22:22:40 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 29 Jan 2020 03:22:40 +0000
Subject: [issue39320] Handle unpacking of */** arguments and rvalues in the
 compiler
In-Reply-To: <1578918490.54.0.342025462897.issue39320@roundup.psfhosted.org>
Message-ID: <1580268160.58.0.395620156299.issue39320@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +17623
pull_request: https://github.com/python/cpython/pull/18243

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39320>
_______________________________________

From report at bugs.python.org  Tue Jan 28 22:22:47 2020
From: report at bugs.python.org (Joseph Gordon)
Date: Wed, 29 Jan 2020 03:22:47 +0000
Subject: [issue24249] unittest API for detecting test failure in
 cleanup/teardown
In-Reply-To: <1432155715.32.0.956645145974.issue24249@psf.upfronthosting.co.za>
Message-ID: <1580268167.05.0.747901826952.issue24249@roundup.psfhosted.org>


Change by Joseph Gordon <j.gordon.matthew at gmail.com>:


----------
nosy:  -josephgordon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24249>
_______________________________________

From report at bugs.python.org  Tue Jan 28 22:23:01 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 29 Jan 2020 03:23:01 +0000
Subject: [issue39320] Handle unpacking of */** arguments and rvalues in the
 compiler
In-Reply-To: <1578918490.54.0.342025462897.issue39320@roundup.psfhosted.org>
Message-ID: <1580268180.99.0.431640507584.issue39320@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39320>
_______________________________________

From report at bugs.python.org  Tue Jan 28 22:23:05 2020
From: report at bugs.python.org (Joseph Gordon)
Date: Wed, 29 Jan 2020 03:23:05 +0000
Subject: [issue25661] tokenize.untokenize does not maintain the order of
 tabbed indentations and leading spaces
In-Reply-To: <1447881207.88.0.934848299376.issue25661@psf.upfronthosting.co.za>
Message-ID: <1580268185.32.0.836291081366.issue25661@roundup.psfhosted.org>


Change by Joseph Gordon <j.gordon.matthew at gmail.com>:


----------
nosy:  -josephgordon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25661>
_______________________________________

From report at bugs.python.org  Tue Jan 28 22:23:22 2020
From: report at bugs.python.org (Joseph Gordon)
Date: Wed, 29 Jan 2020 03:23:22 +0000
Subject: [issue25597] unittest.mock does not wrap dunder methods (__getitem__
 etc)
In-Reply-To: <1447174958.96.0.448093662654.issue25597@psf.upfronthosting.co.za>
Message-ID: <1580268202.04.0.241451218583.issue25597@roundup.psfhosted.org>


Change by Joseph Gordon <j.gordon.matthew at gmail.com>:


----------
nosy:  -josephgordon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25597>
_______________________________________

From report at bugs.python.org  Tue Jan 28 22:27:46 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 29 Jan 2020 03:27:46 +0000
Subject: [issue25597] unittest.mock does not wrap dunder methods (__getitem__
 etc)
In-Reply-To: <1447174958.96.0.448093662654.issue25597@psf.upfronthosting.co.za>
Message-ID: <1580268466.38.0.221673781674.issue25597@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25597>
_______________________________________

From report at bugs.python.org  Tue Jan 28 23:03:13 2020
From: report at bugs.python.org (Orion Poplawski)
Date: Wed, 29 Jan 2020 04:03:13 +0000
Subject: [issue39482] Write 2to3 fixer for MutableMapping
Message-ID: <1580270593.04.0.0568532174463.issue39482@roundup.psfhosted.org>


New submission from Orion Poplawski <orion at cora.nwra.com>:

fail2ban currently relies on 2to3 for python 3 support.  Build now fails with python 3.9:

Traceback (most recent call last):
  File "/builddir/build/BUILD/fail2ban-0.11.1/bin/fail2ban-testcases", line 61, in <module>
    tests = gatherTests(regexps, opts)
  File "./fail2ban/tests/utils.py", line 373, in gatherTests
    from . import clientreadertestcase
  File "./fail2ban/tests/clientreadertestcase.py", line 34, in <module>
    from ..client.jailreader import JailReader, extractOptions, splitWithOptions
  File "./fail2ban/client/jailreader.py", line 34, in <module>
    from .actionreader import ActionReader
  File "./fail2ban/client/actionreader.py", line 31, in <module>
    from ..server.action import CommandAction
  File "./fail2ban/server/action.py", line 33, in <module>
    from collections import MutableMapping
ImportError: cannot import name 'MutableMapping' from 'collections' (/usr/lib64/python3.9/collections/__init__.py)

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 360936
nosy: opoplawski
priority: normal
severity: normal
status: open
title: Write 2to3 fixer for MutableMapping
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39482>
_______________________________________

From report at bugs.python.org  Tue Jan 28 23:11:01 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 29 Jan 2020 04:11:01 +0000
Subject: [issue39482] Write 2to3 fixer for MutableMapping
In-Reply-To: <1580270593.04.0.0568532174463.issue39482@roundup.psfhosted.org>
Message-ID: <1580271061.08.0.197713734317.issue39482@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +benjamin.peterson, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39482>
_______________________________________

From report at bugs.python.org  Tue Jan 28 23:44:56 2020
From: report at bugs.python.org (Sushma)
Date: Wed, 29 Jan 2020 04:44:56 +0000
Subject: [issue39476] Not convinced with the dynamic data type assignment
In-Reply-To: <1580216444.11.0.107613114436.issue39476@roundup.psfhosted.org>
Message-ID: <CAO8uZi7ERdh5TXotmk00z_srTmigNnVt2wxz6f2_eZm2UVkDWA@mail.gmail.com>


Sushma <sush0907 at gmail.com> added the comment:

Thank you

On Tue, Jan 28, 2020, 6:30 PM Steven D'Aprano <report at bugs.python.org>
wrote:

>
> Steven D'Aprano <steve+python at pearwood.info> added the comment:
>
> The "num" variable is not a number, it *is* a string. Just because you
> call it "num" doesn't magically turn it into a number. The `input` function
> returns a string.
>
> You might be thinking of Python 2.7 where `input` automatically evaluated
> the string as Python code. Python 3 does not do that. If you want to
> convert the string result of `input` to be a float or an int or some other
> type, you need to call the `float` or `int` functions.
>
> ----------
> nosy: +steven.daprano
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue39476>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39476>
_______________________________________

From report at bugs.python.org  Wed Jan 29 00:43:57 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 29 Jan 2020 05:43:57 +0000
Subject: [issue39482] Write 2to3 fixer for MutableMapping
In-Reply-To: <1580270593.04.0.0568532174463.issue39482@roundup.psfhosted.org>
Message-ID: <1580276637.56.0.555371207238.issue39482@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39482>
_______________________________________

From report at bugs.python.org  Wed Jan 29 02:09:34 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 29 Jan 2020 07:09:34 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1580281773.99.0.152847127663.issue36051@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset d07d9f4c43bc85a77021bcc7d77643f8ebb605cf by Bruce Merry in branch 'master':
bpo-36051: Drop GIL during large bytes.join() (GH-17757)
https://github.com/python/cpython/commit/d07d9f4c43bc85a77021bcc7d77643f8ebb605cf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Wed Jan 29 02:10:10 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 29 Jan 2020 07:10:10 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1580281810.98.0.291104208677.issue36051@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Wed Jan 29 02:13:43 2020
From: report at bugs.python.org (Aurora)
Date: Wed, 29 Jan 2020 07:13:43 +0000
Subject: [issue39480] referendum reference is needlessly annoying
In-Reply-To: <1580231234.47.0.658599858582.issue39480@roundup.psfhosted.org>
Message-ID: <1580282023.19.0.823014813356.issue39480@roundup.psfhosted.org>


Aurora <auroralanes at pm.me> added the comment:

This example is practically against Python's diversity statement.

----------
nosy: +opensource-assist

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39480>
_______________________________________

From report at bugs.python.org  Wed Jan 29 02:23:57 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 29 Jan 2020 07:23:57 +0000
Subject: [issue14715] test.support.DirsOnSysPath should be replaced by
 importlib.test.util.import_state
In-Reply-To: <1336079069.84.0.625762752869.issue14715@psf.upfronthosting.co.za>
Message-ID: <1580282637.31.0.475999088641.issue14715@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't think so. I don't think the patch even did what I wanted it to do. I'll close it.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14715>
_______________________________________

From report at bugs.python.org  Wed Jan 29 03:19:32 2020
From: report at bugs.python.org (Ananthakrishnan A S)
Date: Wed, 29 Jan 2020 08:19:32 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580285972.48.0.785664788337.issue39479@roundup.psfhosted.org>


Ananthakrishnan A S <ananthakrishnan15.2001 at gmail.com> added the comment:

I agree with Vedran ?a?i?.As the modules are not made for one person but it is for the ease of coding.There are so many functions which i don't use but used by other people.We are using functions to make coding easy and if lcm function is added many people will find it usefull.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Wed Jan 29 03:44:34 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Wed, 29 Jan 2020 08:44:34 +0000
Subject: [issue39482] Write 2to3 fixer for collections.abc imports
In-Reply-To: <1580270593.04.0.0568532174463.issue39482@roundup.psfhosted.org>
Message-ID: <1580287474.47.0.0838252941454.issue39482@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
nosy: +hroncok
title: Write 2to3 fixer for MutableMapping -> Write 2to3 fixer for collections.abc imports

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39482>
_______________________________________

From report at bugs.python.org  Wed Jan 29 04:13:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 09:13:54 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580289234.21.0.210807772097.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> [dje at rawhide ~]$ python3 -c 'import os; os.utime("testfn", (4386268800, 4386268800))'
> [dje at rawhide ~]$ stat testfn
> (...)
> Modify: 2038-01-18 22:14:07.000000000 -0500

Oh. It means that os.utime() replaces mtime=4386268800 with a value close to INT_MAX (2**31-1) to workaround the year 2038 bug.

But the buildbot worker runs Fedora Rawhide and uses the architecture s390x with is a 64-bit system: sizeof(time_t)=8. The glibc is not supposed to change mtime on such platform.

I wrote attached mtime.c which is supposed to reproduce the issue.

Example on my Fedora Rawhide x86-64 VM (glibc-2.30.9000-31.fc32.x86_64):
---
$ gcc mtime.c -o mtime && ./mtime
uname -a:
Linux rawhide 5.5.0-0.rc6.git3.1.fc32.x86_64 #1 SMP Fri Jan 17 18:29:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
sizeof(time_t) = 8 bytes
sizeof(void*) = 8 bytes

open(testfn, O_WRONLY | O_CREAT)
utimensat(AT_FDCWD, testfn, {atime=mtime=4386268800.0}, 0)
stat(testfn)
st.st_mtime = 4386268800
st.st_mtim.tv_nsec = 0
(ignored: st.st_mtime.tv_sec = 0)
unlink(testfn)
---

I get "st.st_mtime = 4386268800" as expected.

----------
Added file: https://bugs.python.org/file48871/mtime.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 04:23:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 09:23:47 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580289827.39.0.658519673896.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm now curious which syscalls are used by the glibc to implement utimensat() and stat().

On a ppc64le Fedora Rawhide running Linux kernel 5.4.8-200.fc31.ppc64le with glibc 2.30.9000, I get:

$ sudo dnf install -y strace # if neeeded
$ strace -o trace ./mtime
(...)

$ grep -E '^(utime|stat)' trace 
utimensat(AT_FDCWD, "testfn", [{tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T00:00:00+0000 */, {tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T00:00:00+0000 */], 0) = 0
stat("testfn", {st_mode=S_IFREG|000, st_size=0, ...}) = 0

=> the glibc uses utimensat() and stat() syscalls.

I get the same syscalls on a x64-64 Fedora Rawhide (Linux kernel 5.5.0-0.rc6.git3.1.fc32.x86_64, libc 2.30.9000):

$ grep -E '^(utime|stat)' trace 
utimensat(AT_FDCWD, "testfn", [{tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T01:00:00+0100 */, {tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T01:00:00+0100 */], 0) = 0
stat("testfn", {st_mode=S_IFREG|000, st_size=0, ...}) = 0

Note: I use "uname -r" to get the Linux kernel version and I run directly "/lib64/libc.so.6" to get the glibc version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 04:25:16 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 29 Jan 2020 09:25:16 +0000
Subject: [issue39482] Write 2to3 fixer for collections.abc imports
In-Reply-To: <1580270593.04.0.0568532174463.issue39482@roundup.psfhosted.org>
Message-ID: <1580289916.02.0.493214390978.issue39482@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17624
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18245

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39482>
_______________________________________

From report at bugs.python.org  Wed Jan 29 04:36:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 09:36:41 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580290601.72.0.692435751493.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

glibc commit adding support for utimensat_time64() syscall:
https://sourceware.org/git/?p=glibc.git;a=commit;h=f5b6fd258b6dd520403a20024e58cb491aca4cbd

See also: https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 05:05:47 2020
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Wed, 29 Jan 2020 10:05:47 +0000
Subject: [issue25661] tokenize.untokenize does not maintain the order of
 tabbed indentations and leading spaces
In-Reply-To: <1447881207.88.0.934848299376.issue25661@psf.upfronthosting.co.za>
Message-ID: <1580292347.98.0.753380918757.issue25661@roundup.psfhosted.org>


Henk-Jaap Wagenaar <wagenaarhenkjaap at gmail.com> added the comment:

Python 2.7 is end-of-life, see e.g. https://www.python.org/doc/sunset-python-2/ so this is unlikely to be fixed.

This behaviour continues on Python 3 it seems (I used 3.8.1), *however* on Python 3 this is not valid code as it mixes spaces and tabs, see e.g. https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

I think therefore this can be closed, though I might well be mistaken.

----------
nosy: +Henk-Jaap Wagenaar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25661>
_______________________________________

From report at bugs.python.org  Wed Jan 29 05:23:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 10:23:47 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580293427.9.0.948143152783.issue39401@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I added https://python-security.readthedocs.io/vuln/unsafe-dll-load-windows-7.html to track fixes in all branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Wed Jan 29 05:25:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 10:25:59 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580293559.05.0.659453082656.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I failed to reproduce the issue on s390x Fedora Rawhide, Linux kernel 5.5.0-0.rc4.git2.1.fc32.s390x, glibc-2.30.9000-31.fc32.s390x.

I tested filesystem nfs and tmpfs.

test_add_file_after_2107() pass.

[vstinner at devel10 ~]$ uname -r
5.5.0-0.rc4.git2.1.fc32.s390x

[vstinner at devel10 ~]$ rpm -q glibc
glibc-2.30.9000-31.fc32.s390x

[vstinner at devel10 ~]$ strace -o trace ./mtime
uname -a:
Linux devel10.s390.bos.redhat.com 5.5.0-0.rc4.git2.1.fc32.s390x #1 SMP Fri Jan 3 20:19:26 UTC 2020 s390x s390x s390x GNU/Linux
sizeof(time_t) = 8 bytes
sizeof(void*) = 8 bytes

open(testfn, O_WRONLY | O_CREAT)
utimensat(AT_FDCWD, testfn, {atime=mtime=4386268800.0}, 0)
stat(testfn)
st.st_mtime = 4386268800
st.st_mtim.tv_nsec = 0
(ignored: st.st_mtime.tv_sec = 0)
unlink(testfn)

[vstinner at devel10 ~]$ grep -E '^(utime|stat)' trace 
utimensat(AT_FDCWD, "testfn", [{tv_sec=4386268800, tv_nsec=0} /* 2108-12-29T19:00:00-0500 */, {tv_sec=4386268800, tv_nsec=0} /* 2108-12-29T19:00:00-0500 */], 0) = 0
stat("testfn", {st_mode=S_IFREG|041, st_size=0, ...}) = 0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 05:41:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 10:41:16 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580294476.11.0.547222709323.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I failed to reproduce the issue on s390x Fedora Rawhide, Linux kernel 5.5.0-0.rc4.git2.1.fc32.s390x, glibc-2.30.9000-31.fc32.s390x.

I still cannot reproduce after a "dnf upgrade -y":

* Linux 5.5.0-0.rc6.git3.1.fc32.s390x
* glibc-2.30.9000-31.fc32.s390x

I tested attached mtime.c and Python test_add_file_after_2107() on nfs and tmpfs filesystems.

The s390x Fedora Rawhide 3.x buildbot worker where the bug occurs uses the same Linux kernel (5.5.0-0.rc6.git3.1.fc32.s390x) and it looks like the same glibc version (glibc 2.30.9000). Checking "rpm -q glibc" would say if it's exactly the same Fedora package.

David: what is the GCC version? (rpm -q gcc)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 06:00:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 11:00:50 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580295650.21.0.323254133211.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Summary:

* test_zipfile.test_add_file_after_2107() fails on Fedora Rawhide 3.x
* Bug seen on Python 3.8 and Python 3.9
* Bug seen on s390x and x86-64 architectures
* It seems like the bug occurs in os.utime() with atime=mtime=4386268800 => stat returns mtime=2147483647
* It may be a recent change in the glibc to workaround year 2038 bug

Failure on x86-64 Fedora Rawhide, on Fedora Koji build server:

* https://koji.fedoraproject.org/koji/taskinfo?taskID=40870460
* Linux 5.4.8-200.fc31.x86_64
* glibc 2.30.9000
* gcc (GCC) 10.0.1 20200121 (Red Hat 10.0.1-0.4)
* utimensat() available

Failure on "s390x Fedora Rawhide 3.x" buildbot worker:

* https://buildbot.python.org/all/#/builders/323/builds/27
* Linux 5.5.0-0.rc6.git3.1.fc32.s390x
* glibc 2.30.9000
* gcc (GCC) 10.0.1 20200121 (Red Hat 10.0.1-0.4)
* utimensat() available

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 06:00:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 11:00:54 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580295654.76.0.952067119862.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Next question: does the issue come from the glibc or the filesystem? Attached mtime.c should ease debug. If you reproduce the issue, please test different filesystem and report which filesystems you tested.

To detect the filesystem used by a directory, I'm using df to find the mount point (ex: "/home") and then mount to get the filesystem:

$ df .
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p3  461G  368G   93G  80% /home

$ mount|grep /home
/dev/nvme0n1p3 on /home type btrfs (rw,relatime,seclabel,ssd,space_cache,subvolid=258,subvol=/home)

=> btrfs here

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 06:08:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 11:08:21 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580296101.29.0.289439879951.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I failed to reproduce the bug on 3 machines.

My x86-64 Fedora VM:

* Linux 5.5.0-0.rc6.git3.1.fc32.x86_64
* glibc-2.30.9000-31.fc32.x86_64
* gcc-10.0.1-0.5.fc32.x86_64
* utimensat() available
* I tested ext4 (/home) and tmpfs (/tmp)

ppc64le mock:

* Linux 5.4.8-200.fc31.ppc64le (kernel of the Fedora 31 host)
* glibc-2.30.9000-31.fc32.ppc64le
* gcc-10.0.1-0.5.fc32.ppc64le
* I tested ext4 (/home) and tmpfs (/tmp)

s390x devel machine:

* Linux 5.5.0-0.rc6.git3.1.fc32.s390x
* glibc-2.30.9000-31.fc32.s390x
* gcc-10.0.1-0.5.fc32.s390x
* I tested nfs4 (/home) and tmpfs (/tmp)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 06:19:15 2020
From: report at bugs.python.org (Florian Weimer)
Date: Wed, 29 Jan 2020 11:19:15 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580296755.33.0.903971589055.issue39460@roundup.psfhosted.org>


Florian Weimer <fweimer at redhat.com> added the comment:

I believe you might be observing an XFS limitation in combination with a Linux VFS bug.

On disk, XFS only supports 32-bit timestamps:

typedef struct xfs_timestamp {
	__be32		t_sec;		/* timestamp seconds */
	__be32		t_nsec;		/* timestamp nanoseconds */
} xfs_timestamp_t;

This is on the roadmap being fixed.

However, the Linux VFS code does not appear to know about this. It caches the full 64-bit value. You only see the truncated value if it is read back from disk:

# touch -t 222201020304 /tmp/t
# ls -l /tmp/t
-rw-r--r--. 1 root root 0 Jan  2  2222 /tmp/t
# echo 3 > /proc/sys/vm/drop_caches 
# ls -l /tmp/t
-rw-r--r--. 1 root root 0 Oct 19  1949 /tmp/t

This is a bug in the Linux VFS layer.

----------
nosy: +fweimer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 06:21:17 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Jan 2020 11:21:17 +0000
Subject: [issue39153] Clarify refcounting semantics of PyDict_SetItem[String]
In-Reply-To: <1577626439.88.0.846596028568.issue39153@roundup.psfhosted.org>
Message-ID: <1580296877.96.0.742012488413.issue39153@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset e1e80002e28e1055f399a20918c49d50d093709e by Joannah Nanjekye in branch 'master':
bpo-39153: Clarify C API *SetItem refcounting semantics (GH-18220)
https://github.com/python/cpython/commit/e1e80002e28e1055f399a20918c49d50d093709e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39153>
_______________________________________

From report at bugs.python.org  Wed Jan 29 06:21:20 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jan 2020 11:21:20 +0000
Subject: [issue39153] Clarify refcounting semantics of PyDict_SetItem[String]
In-Reply-To: <1577626439.88.0.846596028568.issue39153@roundup.psfhosted.org>
Message-ID: <1580296880.76.0.958192593213.issue39153@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17625
pull_request: https://github.com/python/cpython/pull/18246

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39153>
_______________________________________

From report at bugs.python.org  Wed Jan 29 06:29:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 11:29:41 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580297381.93.0.989779315406.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I managed to reproduce the issue on Fedora 31 on a XFS filesystem:

$ touch testfn
$ strace -o trace python3 -c 'import os; os.utime("testfn", (4386268800, 4386268800))'
$ grep ^utimensat trace
utimensat(AT_FDCWD, "testfn", [{tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T01:00:00+0100 */, {tv_sec=4386268800, tv_nsec=0} /* 2108-12-30T01:00:00+0100 */], 0) = 0
$ stat testfn
(...)
Modify: 2038-01-19 04:14:07.000000000 +0100
(...)

It looks like a Linux kernel issue in the XFS filesystem: I don't think that mtime should be *silently* truncated to 2147483647.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 06:29:42 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jan 2020 11:29:42 +0000
Subject: [issue39153] Clarify refcounting semantics of PyDict_SetItem[String]
In-Reply-To: <1577626439.88.0.846596028568.issue39153@roundup.psfhosted.org>
Message-ID: <1580297382.85.0.689743294471.issue39153@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 526523c19322169a7f7507d9da291053df979412 by Miss Islington (bot) in branch '3.8':
bpo-39153: Clarify C API *SetItem refcounting semantics (GH-18220)
https://github.com/python/cpython/commit/526523c19322169a7f7507d9da291053df979412


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39153>
_______________________________________

From report at bugs.python.org  Wed Jan 29 06:36:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 11:36:58 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580297818.78.0.810941615618.issue39460@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17626
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18247

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 06:51:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 11:51:38 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x: Linux VFS/XFS bug
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580298698.33.0.371877248102.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The kernel bug is now tracked at https://bugzilla.redhat.com/show_bug.cgi?id=1795576

I wrote PR 18247 to skip the test.

I suggest to leave this issue is open until the kernel is fixed: until the test is no longer skipped.

----------
title: test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x -> test_zipfile: test_add_file_after_2107() sometimes fails on Fedora Rawhide 3.x: Linux VFS/XFS bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 06:52:27 2020
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCa0LDQt9Cw0L3RhtC10LI=?=)
Date: Wed, 29 Jan 2020 11:52:27 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
Message-ID: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>


New submission from ?????? ???????? <heckad at yandex.ru>:

Sometimes need get loop from another place and run corutine in it. For example when use teleton lib. Example from this lib https://docs.telethon.dev/en/latest/basic/signing-in.html#id2 suggests using ```client.loop.run_until_complete``` but it's not handle errors like in run method.

----------
components: asyncio
messages: 360957
nosy: asvetlov, heckad, yselivanov
priority: normal
severity: normal
status: open
title: Proposial add loop parametr to run in asyncio
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39483>
_______________________________________

From report at bugs.python.org  Wed Jan 29 07:03:19 2020
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCa0LDQt9Cw0L3RhtC10LI=?=)
Date: Wed, 29 Jan 2020 12:03:19 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1580299399.12.0.740913524109.issue39483@roundup.psfhosted.org>


Change by ?????? ???????? <heckad at yandex.ru>:


----------
keywords: +patch
pull_requests: +17627
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18248

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39483>
_______________________________________

From report at bugs.python.org  Wed Jan 29 08:02:45 2020
From: report at bugs.python.org (Vincent Michel)
Date: Wed, 29 Jan 2020 13:02:45 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
Message-ID: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>


New submission from Vincent Michel <vxgmichel at gmail.com>:

On windows, the timestamps produced by time.time() often end up being equal because of the 15 ms resolution:

    >>> time.time(), time.time()
    (1580301469.6875124, 1580301469.6875124)

The problem I noticed is that a value produced by time_ns() might end up being higher then a value produced time() even though time_ns() was called before:

    >>> a, b = time.time_ns(), time.time()
    >>> a, b
    (1580301619906185300, 1580301619.9061852)
    >>> a / 10**9 <= b
    False

This break in causality can lead to very obscure bugs since timestamps are often compared to one another. Note that those timestamps can also come from non-python sources, i.e a C program using `GetSystemTimeAsFileTime`.

This problem seems to be related to the conversion `_PyTime_AsSecondsDouble`:
https://github.com/python/cpython/blob/f1c19031fd5f4cf6faad539e30796b42954527db/Python/pytime.c#L460-L461

    # Float produced by `time.time()`
    >>> b.hex()
    '0x1.78c5f4cf9fef0p+30'
    # Basically what `_PyTime_AsSecondsDouble` does:
    >>> (float(a) / 10**9).hex()
    '0x1.78c5f4cf9fef0p+30'
    # What I would expect from `time.time()`
    >>> (a / 10**9).hex()
    '0x1.78c5f4cf9fef1p+30'

However I don't know if this would be enough to fix all causality issues since, as Tim Peters noted in another thread:

> Just noting for the record that a C double (time.time() result) isn't quite enough to hold a full-precision Windows time regardless

(https://bugs.python.org/issue19738#msg204112)

----------
components: Library (Lib)
messages: 360958
nosy: vxgmichel
priority: normal
severity: normal
status: open
title: time_ns() and time() cannot be compared on windows
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Wed Jan 29 08:13:46 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 29 Jan 2020 13:13:46 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1580303626.14.0.492715136901.issue39483@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

-1.
I rather suggest updating telethon example in the following matter:

async with main():
    with TelegramClient('anon', api_id, api_hash) as client:
        await client.send_message('me', 'Hello, myself!')

You PR brings more problems than fixes: the loop is closed after the first usage, the next call with the same loop fails.
I don't think that we should support such tricky mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39483>
_______________________________________

From report at bugs.python.org  Wed Jan 29 08:38:46 2020
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCa0LDQt9Cw0L3RhtC10LI=?=)
Date: Wed, 29 Jan 2020 13:38:46 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1580305126.85.0.896100424577.issue39483@roundup.psfhosted.org>


?????? ???????? <heckad at yandex.ru> added the comment:

I create the client object in `bot` file. If I import it then it creates loop when will import and then when I run it I will get errors attaching to a different loop. Another way to use `import` statement in main. This is blocking code. What to choose?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39483>
_______________________________________

From report at bugs.python.org  Wed Jan 29 08:49:55 2020
From: report at bugs.python.org (Carl Friedrich Bolz-Tereick)
Date: Wed, 29 Jan 2020 13:49:55 +0000
Subject: [issue39485] Bug in mock running on PyPy3
Message-ID: <1580305795.64.0.514699285902.issue39485@roundup.psfhosted.org>


New submission from Carl Friedrich Bolz-Tereick <cfbolz at gmx.de>:

One of the new-in-3.8 tests for unittest.mock, test_spec_has_descriptor_returning_function, is failing on PyPy. This exposes a bug in unittest.mock. The bug is most noticeable on PyPy, where it can be triggered by simply writing a slightly weird descriptor (CrazyDescriptor in the test). Getting it to trigger on CPython would be possible too, by implementing the same descriptor in C, but I did not actually do that.

The relevant part of the test looks like this:

from unittest.mock import create_autospec

class CrazyDescriptor(object):
    def __get__(self, obj, type_):
        if obj is None:
            return lambda x: None

class MyClass(object):

    some_attr = CrazyDescriptor()

mock = create_autospec(MyClass)
mock.some_attr(1)

On CPython this just works, on PyPy it fails with:

Traceback (most recent call last):
  File "x.py", line 13, in <module>
    mock.some_attr(1)
  File "/home/cfbolz/bin/.pyenv/versions/pypy3.6-7.2.0/lib-python/3/unittest/mock.py", line 938, in __call__
    _mock_self._mock_check_sig(*args, **kwargs)
  File "/home/cfbolz/bin/.pyenv/versions/pypy3.6-7.2.0/lib-python/3/unittest/mock.py", line 101, in checksig
    sig.bind(*args, **kwargs)
  File "/home/cfbolz/bin/.pyenv/versions/pypy3.6-7.2.0/lib-python/3/inspect.py", line 3034, in bind
    return args[0]._bind(args[1:], kwargs)
  File "/home/cfbolz/bin/.pyenv/versions/pypy3.6-7.2.0/lib-python/3/inspect.py", line 2955, in _bind
    raise TypeError('too many positional arguments') from None
TypeError: too many positional arguments

The reason for this problem is that mock deduced that MyClass.some_attr is a method on PyPy. Since mock thinks the lambda returned by the descriptor is a method, it adds self as an argument, which leads to the TypeError.

Checking whether something is a method is done by _must_skip in mock.py. The relevant condition is this one:

        elif isinstance(getattr(result, '__get__', None), MethodWrapperTypes):
            # Normal method => skip if looked up on type
            # (if looked up on instance, self is already skipped)
            return is_type
        else:
            return False

MethodWrapperTypes is defined as:

MethodWrapperTypes = (
    type(ANY.__eq__.__get__),
)

which is just types.MethodType on PyPy, because there is no such thing as a method wrapper (the builtin types look pretty much like python-defined types in PyPy).

On PyPy the condition isinstance(getattr...) is thus True for all descriptors! so as soon as result has a __get__, it counts as a method, even in the above case where it's a custom descriptor.


Now even on CPython the condition makes no sense to me. It would be True for a C-defined version of CrazyDescriptor, it's just not a good way to check whether result is a method.

I would propose to replace the condition with the much more straightforward check:

        elif isinstance(result, FunctionTypes):
            ...

something is a method if it's a function on the class. Doing that change makes the test pass on PyPy, and doesn't introduce any test failures on CPython either.

Will open a pull request.

----------
messages: 360961
nosy: Carl.Friedrich.Bolz, cjw296
priority: normal
severity: normal
status: open
title: Bug in mock running on PyPy3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39485>
_______________________________________

From report at bugs.python.org  Wed Jan 29 09:07:07 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 29 Jan 2020 14:07:07 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1580306827.78.0.870911360151.issue39483@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

A client that creates a loop implicitly in the constructor is a weird design from my perspective.

You are free to use it, sure -- but please let us keep the freedom to not support such corner cases by asyncio.run()

Sorry, I don't know the telethon library good enough to suggest the best workaround.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39483>
_______________________________________

From report at bugs.python.org  Wed Jan 29 09:09:08 2020
From: report at bugs.python.org (Carl Friedrich Bolz-Tereick)
Date: Wed, 29 Jan 2020 14:09:08 +0000
Subject: [issue39485] Bug in mock running on PyPy3
In-Reply-To: <1580305795.64.0.514699285902.issue39485@roundup.psfhosted.org>
Message-ID: <1580306948.42.0.426823317265.issue39485@roundup.psfhosted.org>


Change by Carl Friedrich Bolz-Tereick <cfbolz at gmx.de>:


----------
keywords: +patch
pull_requests: +17629
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18252

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39485>
_______________________________________

From report at bugs.python.org  Wed Jan 29 09:23:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 14:23:36 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x: Linux VFS/XFS bug
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580307816.46.0.336770310815.issue39460@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 3cb49b62e61208efcefbc04414e769fc173f205d by Victor Stinner in branch 'master':
bpo-39460: Fix test_zipfile.test_add_file_after_2107() (GH-18247)
https://github.com/python/cpython/commit/3cb49b62e61208efcefbc04414e769fc173f205d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 09:25:52 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jan 2020 14:25:52 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x: Linux VFS/XFS bug
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580307952.13.0.400572497543.issue39460@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17630
pull_request: https://github.com/python/cpython/pull/18253

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 09:41:54 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jan 2020 14:41:54 +0000
Subject: [issue39460] test_zipfile: test_add_file_after_2107() sometimes fails
 on Fedora Rawhide 3.x: Linux VFS/XFS bug
In-Reply-To: <1580117090.75.0.217568835577.issue39460@roundup.psfhosted.org>
Message-ID: <1580308914.44.0.779892106437.issue39460@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2b675f0c8fd96f61977f6dc636f44fbd5587b6b3 by Miss Islington (bot) in branch '3.8':
bpo-39460: Fix test_zipfile.test_add_file_after_2107() (GH-18247)
https://github.com/python/cpython/commit/2b675f0c8fd96f61977f6dc636f44fbd5587b6b3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39460>
_______________________________________

From report at bugs.python.org  Wed Jan 29 09:49:09 2020
From: report at bugs.python.org (Carl Friedrich Bolz-Tereick)
Date: Wed, 29 Jan 2020 14:49:09 +0000
Subject: [issue39486] bug in %-formatting in Python,
 related to escaped %-characters
Message-ID: <1580309349.27.0.404972763443.issue39486@roundup.psfhosted.org>


New submission from Carl Friedrich Bolz-Tereick <cfbolz at gmx.de>:

The following behaviour of %-formatting changed between Python3.6 and Python3.7, and is in my opinion a bug that was introduced.

So far, it has been possible to add conversion flags to a conversion specifier in %-formatting, even if the conversion is '%' (meaning a literal % is emitted and no argument consumed).

Eg this works in Python3.6:

>>>> "%+%abc% %" % ()
'%abc%'

The conversion flags '+' and ' ' are ignored.

Was it discussed and documented anywhere that this is now an error? Because Python3.7 has the following strange behaviour instead:

>>> "%+%abc% %" % ()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: not enough arguments for format string

That error message is just confusing, because the amount of arguments is not the problem here. If I pass a dict (thus making the number of arguments irrelevant) I get instead:

>>> "%+%abc% %" % {}
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: unsupported format character '%' (0x25) at index 2

(also a confusing message, because '%' is a perfectly fine format character)

In my opinion this behaviour should either be reverted to how Python3.6 worked, or the new restrictions should be documented and the error messages improved.

----------
messages: 360965
nosy: Carl.Friedrich.Bolz
priority: normal
severity: normal
status: open
title: bug in %-formatting in Python, related to escaped %-characters
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39486>
_______________________________________

From report at bugs.python.org  Wed Jan 29 09:52:08 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 29 Jan 2020 14:52:08 +0000
Subject: [issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code
Message-ID: <1580309528.55.0.307294388242.issue39487@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

As stinner said in issue19514

those _Py_IDENTIFIER should be merged:

./Modules/_ctypes/_ctypes.c:1054:    _Py_IDENTIFIER(_type_);
./Modules/_ctypes/_ctypes.c:1132:    _Py_IDENTIFIER(_type_);
./Modules/_ctypes/_ctypes.c:1494:    _Py_IDENTIFIER(_type_);
./Modules/_ctypes/_ctypes.c:2071:    _Py_IDENTIFIER(_type_);

./Modules/_ctypes/_ctypes.c:1692:    _Py_IDENTIFIER(_as_parameter_);
./Modules/_ctypes/_ctypes.c:1759:    _Py_IDENTIFIER(_as_parameter_);
./Modules/_ctypes/_ctypes.c:1826:    _Py_IDENTIFIER(_as_parameter_);
./Modules/_ctypes/_ctypes.c:2256:    _Py_IDENTIFIER(_as_parameter_);

./Modules/_ctypes/_ctypes.c:2474:    _Py_IDENTIFIER(_check_retval_);
./Modules/_ctypes/_ctypes.c:3280:    _Py_IDENTIFIER(_check_retval_);

./Modules/_pickle.c:3560:    _Py_IDENTIFIER(__name__);
./Modules/_pickle.c:3979:        _Py_IDENTIFIER(__name__);

./Modules/_pickle.c:4042:            _Py_IDENTIFIER(__new__);
./Modules/_pickle.c:5771:        _Py_IDENTIFIER(__new__);

./Python/ceval.c:5058:    _Py_IDENTIFIER(__name__);
./Python/ceval.c:5134:    _Py_IDENTIFIER(__name__);

./Python/import.c:386:    _Py_IDENTIFIER(__spec__);
./Python/import.c:1569:    _Py_IDENTIFIER(__spec__);

./Python/import.c:1571:    _Py_IDENTIFIER(__path__);
./Python/import.c:1933:        _Py_IDENTIFIER(__path__);

./Python/_warnings.c:487:    _Py_IDENTIFIER(__name__);
./Python/_warnings.c:821:    _Py_IDENTIFIER(__name__);
./Python/_warnings.c:972:    _Py_IDENTIFIER(__name__);

./Python/errors.c:1012:    _Py_IDENTIFIER(__module__);
./Python/errors.c:1238:    _Py_IDENTIFIER(__module__);

./Objects/bytesobject.c:546:    _Py_IDENTIFIER(__bytes__);
./Objects/bytesobject.c:2488:    _Py_IDENTIFIER(__bytes__);

./Objects/moduleobject.c:61:    _Py_IDENTIFIER(__name__);
./Objects/moduleobject.c:488:    _Py_IDENTIFIER(__name__);
./Objects/moduleobject.c:741:        _Py_IDENTIFIER(__name__);

./Objects/moduleobject.c:62:    _Py_IDENTIFIER(__doc__);
./Objects/moduleobject.c:461:    _Py_IDENTIFIER(__doc__);

./Objects/moduleobject.c:65:    _Py_IDENTIFIER(__spec__);
./Objects/moduleobject.c:744:            _Py_IDENTIFIER(__spec__);

./Objects/iterobject.c:107:    _Py_IDENTIFIER(iter);
./Objects/iterobject.c:247:    _Py_IDENTIFIER(iter);

./Objects/rangeobject.c:760:    _Py_IDENTIFIER(iter);
./Objects/rangeobject.c:918:    _Py_IDENTIFIER(iter);

./Objects/descrobject.c:574:    _Py_IDENTIFIER(getattr);
./Objects/descrobject.c:1243:    _Py_IDENTIFIER(getattr);

./Objects/odictobject.c:899:    _Py_IDENTIFIER(items);
./Objects/odictobject.c:1378:    _Py_IDENTIFIER(items);
./Objects/odictobject.c:2198:    _Py_IDENTIFIER(items);

./Objects/fileobject.c:35:    _Py_IDENTIFIER(open);
./Objects/fileobject.c:550:    _Py_IDENTIFIER(open);


./Objects/typeobject.c:312:        _Py_IDENTIFIER(mro);
./Objects/typeobject.c:1893:        _Py_IDENTIFIER(mro);

----------
components: Interpreter Core
messages: 360966
nosy: shihai1991
priority: normal
severity: normal
status: open
title: Merge duplicated _Py_IDENTIFIER identifiers in C code
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39487>
_______________________________________

From report at bugs.python.org  Wed Jan 29 09:56:14 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 29 Jan 2020 14:56:14 +0000
Subject: [issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code
In-Reply-To: <1580309528.55.0.307294388242.issue39487@roundup.psfhosted.org>
Message-ID: <1580309774.58.0.882724125116.issue39487@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +17631
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18254

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39487>
_______________________________________

From report at bugs.python.org  Wed Jan 29 10:00:16 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 29 Jan 2020 15:00:16 +0000
Subject: [issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code
In-Reply-To: <1580309528.55.0.307294388242.issue39487@roundup.psfhosted.org>
Message-ID: <1580310016.07.0.768214590231.issue39487@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39487>
_______________________________________

From report at bugs.python.org  Wed Jan 29 10:37:00 2020
From: report at bugs.python.org (Eric Snow)
Date: Wed, 29 Jan 2020 15:37:00 +0000
Subject: [issue15600] expose the finder details used by the FileFinder path
 hook
In-Reply-To: <1344483800.66.0.152640034936.issue15600@psf.upfronthosting.co.za>
Message-ID: <1580312220.52.0.680046592481.issue15600@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I have many other things higher on my todo list. :)  I'll re-open this issue if I get back to the project that motivated this (i.e. "source translation via import hooks for filename suffix").

----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15600>
_______________________________________

From report at bugs.python.org  Wed Jan 29 10:37:56 2020
From: report at bugs.python.org (Chris Withers)
Date: Wed, 29 Jan 2020 15:37:56 +0000
Subject: [issue39485] Bug in mock running on PyPy3
In-Reply-To: <1580305795.64.0.514699285902.issue39485@roundup.psfhosted.org>
Message-ID: <1580312276.48.0.704268606691.issue39485@roundup.psfhosted.org>


Change by Chris Withers <chris at withers.org>:


----------
assignee:  -> cjw296

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39485>
_______________________________________

From report at bugs.python.org  Wed Jan 29 10:43:54 2020
From: report at bugs.python.org (Chris Withers)
Date: Wed, 29 Jan 2020 15:43:54 +0000
Subject: [issue39485] Bug in mock running on PyPy3
In-Reply-To: <1580305795.64.0.514699285902.issue39485@roundup.psfhosted.org>
Message-ID: <1580312634.69.0.940126674613.issue39485@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset a327677905956ae0b239ff430a1346dfe265709e by Carl Friedrich Bolz-Tereick in branch 'master':
bpo-39485: fix corner-case in method-detection of mock (GH-18252)
https://github.com/python/cpython/commit/a327677905956ae0b239ff430a1346dfe265709e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39485>
_______________________________________

From report at bugs.python.org  Wed Jan 29 10:44:19 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jan 2020 15:44:19 +0000
Subject: [issue39485] Bug in mock running on PyPy3
In-Reply-To: <1580305795.64.0.514699285902.issue39485@roundup.psfhosted.org>
Message-ID: <1580312659.92.0.778595569351.issue39485@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17632
pull_request: https://github.com/python/cpython/pull/18255

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39485>
_______________________________________

From report at bugs.python.org  Wed Jan 29 10:44:36 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 29 Jan 2020 15:44:36 +0000
Subject: [issue39485] Bug in mock running on PyPy3
In-Reply-To: <1580305795.64.0.514699285902.issue39485@roundup.psfhosted.org>
Message-ID: <1580312676.16.0.237832539958.issue39485@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17633
pull_request: https://github.com/python/cpython/pull/18256

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39485>
_______________________________________

From report at bugs.python.org  Wed Jan 29 11:09:46 2020
From: report at bugs.python.org (Xavier Robin)
Date: Wed, 29 Jan 2020 16:09:46 +0000
Subject: [issue33339] Using default encoding with `subprocess.run()` is not
 obvious
In-Reply-To: <1524472712.16.0.682650639539.issue33339@psf.upfronthosting.co.za>
Message-ID: <1580314186.23.0.349915997832.issue33339@roundup.psfhosted.org>


Change by Xavier Robin <geckolimo at gmail.com>:


----------
nosy: +Xavier Robin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33339>
_______________________________________

From report at bugs.python.org  Wed Jan 29 11:10:31 2020
From: report at bugs.python.org (Chris Withers)
Date: Wed, 29 Jan 2020 16:10:31 +0000
Subject: [issue39485] Bug in mock running on PyPy3
In-Reply-To: <1580305795.64.0.514699285902.issue39485@roundup.psfhosted.org>
Message-ID: <1580314231.41.0.581280039194.issue39485@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset cf0645a17acbc0c4dbbf82434e37637965748bbb by Miss Islington (bot) in branch '3.7':
bpo-39485: fix corner-case in method-detection of mock (GH-18256)
https://github.com/python/cpython/commit/cf0645a17acbc0c4dbbf82434e37637965748bbb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39485>
_______________________________________

From report at bugs.python.org  Wed Jan 29 11:15:39 2020
From: report at bugs.python.org (Chris Withers)
Date: Wed, 29 Jan 2020 16:15:39 +0000
Subject: [issue39485] Bug in mock running on PyPy3
In-Reply-To: <1580305795.64.0.514699285902.issue39485@roundup.psfhosted.org>
Message-ID: <1580314539.32.0.754928865897.issue39485@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset 696d2324cf2a54e20e8d6a6739fa97ba815a8be9 by Miss Islington (bot) in branch '3.8':
bpo-39485: fix corner-case in method-detection of mock (GH-18255)
https://github.com/python/cpython/commit/696d2324cf2a54e20e8d6a6739fa97ba815a8be9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39485>
_______________________________________

From report at bugs.python.org  Wed Jan 29 11:20:19 2020
From: report at bugs.python.org (Chris Withers)
Date: Wed, 29 Jan 2020 16:20:19 +0000
Subject: [issue39485] Bug in mock running on PyPy3
In-Reply-To: <1580305795.64.0.514699285902.issue39485@roundup.psfhosted.org>
Message-ID: <1580314819.08.0.593661526737.issue39485@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

Thank you very much for this, that was a really good catch!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39485>
_______________________________________

From report at bugs.python.org  Wed Jan 29 11:23:20 2020
From: report at bugs.python.org (Eric Snow)
Date: Wed, 29 Jan 2020 16:23:20 +0000
Subject: [issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code
In-Reply-To: <1580309528.55.0.307294388242.issue39487@roundup.psfhosted.org>
Message-ID: <1580315000.89.0.181426214657.issue39487@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FTR:

As Martin noted in #19514, there isn't any performance difference for statics, whether local or global.  For static locals the compiler (at least on linux) generates symbols named as "<name>.<#>" and they are treated as global.

One key difference (again, at least on linux; seen using "nm") is that symbols for static globals preserve identifying information, like the originating source file.  For static locals the filename is not preserved and, when there are duplicates, you do not know from which function a particular symbol comes.  So compiled symbols for static globals are *much* easier to identify in the source than symbols for static locals.

Hence static locals complicate something I'm working on: tooling to identify global variables in our source code.  So I'm a fan of efforts to remove duplicates (and move static locals to the explicit global namespace).  Thank you! :)

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39487>
_______________________________________

From report at bugs.python.org  Wed Jan 29 11:25:00 2020
From: report at bugs.python.org (Chris Withers)
Date: Wed, 29 Jan 2020 16:25:00 +0000
Subject: [issue37972] unittest.mock.call does not chain __getitem__ to another
 _Call object
In-Reply-To: <1567024381.55.0.529292089661.issue37972@roundup.psfhosted.org>
Message-ID: <1580315100.83.0.182980100101.issue37972@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset db5e86adbce12350c26e7ffc2c6673369971a2dc by Chris Withers in branch 'master':
Get mock coverage back to 100% (GH-18228)
https://github.com/python/cpython/commit/db5e86adbce12350c26e7ffc2c6673369971a2dc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37972>
_______________________________________

From report at bugs.python.org  Wed Jan 29 11:50:30 2020
From: report at bugs.python.org (SilentGhost)
Date: Wed, 29 Jan 2020 16:50:30 +0000
Subject: [issue39486] bug in %-formatting in Python,
 related to escaped %-characters
In-Reply-To: <1580309349.27.0.404972763443.issue39486@roundup.psfhosted.org>
Message-ID: <1580316630.69.0.286285990453.issue39486@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

This seemed to be a consequence of #29568.

----------
components: +Interpreter Core
nosy: +SilentGhost
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39486>
_______________________________________

From report at bugs.python.org  Wed Jan 29 12:10:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 17:10:20 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1580317820.24.0.985506271957.issue38323@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> FYI, I'm able to reproduce the hang by running "python -m test -F test_asyncio -m test_close_kill_running". Working on the fix.

Any update on this issue? It's still failing randomly on buildbots. Example:
https://buildbot.python.org/all/#/builders/158/builds/64

Another option is to skip the test_close_kill_running() until it's fixed which usually means forget about it until an user gets the bug for real in production.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Wed Jan 29 12:14:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 17:14:09 +0000
Subject: [issue39488] test_largefile: TestSocketSendfile.test_it() uses too
 much disk space
Message-ID: <1580318049.66.0.254124049267.issue39488@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

TestSocketSendfile.test_it() failed with "OSError: [Errno 28] No space left on device" on PPC64LE Fedora 3.x buildbot.

It also caused troubles on "AMD64 Fedora Rawhide Clang 3.x" worker.

If I recall correctly, it writes like 8 GB of real data, not just empty files made of holes.

I suggest to either remove the test or to use way less disk space.

https://buildbot.python.org/all/#builders/11/builds/259

Traceback (most recent call last):
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/test/test_largefile.py", line 161, in test_it
    shutil.copyfile(TESTFN, TESTFN2)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/shutil.py", line 270, in copyfile
    _fastcopy_sendfile(fsrc, fdst)
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/shutil.py", line 163, in _fastcopy_sendfile
    raise err from None
  File "/home/shager/cpython-buildarea/3.x.edelsohn-fedora-ppc64le/build/Lib/shutil.py", line 149, in _fastcopy_sendfile
    sent = os.sendfile(outfd, infd, offset, blocksize)
OSError: [Errno 28] No space left on device: '@test_38097_tmp' -> '@test_38097_tmp2'

----------
components: Tests
keywords: buildbot
messages: 360976
nosy: giampaolo.rodola, vstinner
priority: normal
severity: normal
status: open
title: test_largefile: TestSocketSendfile.test_it() uses too much disk space
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39488>
_______________________________________

From report at bugs.python.org  Wed Jan 29 12:18:40 2020
From: report at bugs.python.org (Carl Friedrich Bolz-Tereick)
Date: Wed, 29 Jan 2020 17:18:40 +0000
Subject: [issue39486] bug in %-formatting in Python,
 related to escaped %-characters
In-Reply-To: <1580309349.27.0.404972763443.issue39486@roundup.psfhosted.org>
Message-ID: <1580318320.38.0.426267121927.issue39486@roundup.psfhosted.org>


Carl Friedrich Bolz-Tereick <cfbolz at gmx.de> added the comment:

Ok, that means it's intentional. I still think it's missing a documentation change and consistent error messages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39486>
_______________________________________

From report at bugs.python.org  Wed Jan 29 12:21:01 2020
From: report at bugs.python.org (SilentGhost)
Date: Wed, 29 Jan 2020 17:21:01 +0000
Subject: [issue39486] bug in %-formatting in Python,
 related to escaped %-characters
In-Reply-To: <1580309349.27.0.404972763443.issue39486@roundup.psfhosted.org>
Message-ID: <1580318461.88.0.436574635214.issue39486@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39486>
_______________________________________

From report at bugs.python.org  Wed Jan 29 13:16:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 18:16:16 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
Message-ID: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Python has a COUNT_ALLOCS special build which adds sys.getcounts() function and shows statistics on Python types at exit if -X showalloccount command line option is used.

I never ever used this feature and I don't know anyone using it.

But "#ifdef COUNT_ALLOCS" code is scattered all around the code. It requires maintenance. I propose to remove the code to ease maintenance.

Attached PR shows how much code is requires to support this special build.

There are now more advanced tools to have similar features:

* tracemalloc can be used to track memory leaks
* gc.getobjects() can be called frequently to compute statistics on Python types
* There are many tools built around gc.getobjects()

The previous large change related to COUNT_ALLOCS was done in Python 3.6 by bpo-23034:

"The output of a special Python build with defined COUNT_ALLOCS, SHOW_ALLOC_COUNT or SHOW_TRACK_COUNT macros is now off by default. It can be re-enabled using the -X showalloccount option. It now outputs to stderr instead of stdout. (Contributed by Serhiy Storchaka in bpo-23034.)"

https://docs.python.org/dev/whatsnew/3.6.html#changes-in-python-command-behavior

----------
components: Build
messages: 360978
nosy: vstinner
priority: normal
severity: normal
status: open
title: Remove COUNT_ALLOCS special build
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39489>
_______________________________________

From report at bugs.python.org  Wed Jan 29 13:21:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 18:21:50 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580322110.36.0.011173506295.issue39489@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-19527 which discussed COUNT_ALLOCS in 2013.

COUNT_ALLOCS build is documented in Fedora "DebugPythonStacks" wiki page:
https://fedoraproject.org/wiki/Features/DebugPythonStacks#Verify_COUNT_ALLOCS

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39489>
_______________________________________

From report at bugs.python.org  Wed Jan 29 13:22:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 18:22:17 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580322137.81.0.227760336707.issue39489@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17634
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18259

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39489>
_______________________________________

From report at bugs.python.org  Wed Jan 29 13:26:46 2020
From: report at bugs.python.org (Vincent Michel)
Date: Wed, 29 Jan 2020 18:26:46 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580322406.27.0.994848687035.issue39484@roundup.psfhosted.org>


Vincent Michel <vxgmichel at gmail.com> added the comment:

I thought about it a bit more and I realized there is no way to recover the time in hundreds of nanoseconds from the float produced by `time.time()` (since the windows time currently takes 54 bits and will take 55 bits in 2028). 

That means `time()` and `time_ns()` cannot be compared by converting time() to nanoseconds, but it might still make sense to compare them by converting time_ns() to seconds (which is apparently broken at the moment).

If that makes sense, a possible roadmap to tackle this problem would be:
- fix `_PyTime_AsSecondsDouble` so that `time.time_ns() / 10**9 == time.time()`
- add a warning in the documentation that one should be careful when comparing the timestamps produced by `time()` and time_ns()` (in particular, `time()` should not be converted to nanoseconds)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Wed Jan 29 13:50:19 2020
From: report at bugs.python.org (David Edelsohn)
Date: Wed, 29 Jan 2020 18:50:19 +0000
Subject: [issue38628] Issue with ctypes in AIX
In-Reply-To: <1572340643.38.0.935669039099.issue38628@roundup.psfhosted.org>
Message-ID: <1580323819.37.0.713129143433.issue38628@roundup.psfhosted.org>


Change by David Edelsohn <dje.gcc at gmail.com>:


----------
nosy: +David.Edelsohn, Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38628>
_______________________________________

From report at bugs.python.org  Wed Jan 29 14:26:13 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 29 Jan 2020 19:26:13 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580325973.51.0.6142588994.issue39489@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I have never used this feature either.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39489>
_______________________________________

From report at bugs.python.org  Wed Jan 29 14:49:18 2020
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCa0LDQt9Cw0L3RhtC10LI=?=)
Date: Wed, 29 Jan 2020 19:49:18 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1580327358.67.0.983192462161.issue39483@roundup.psfhosted.org>


?????? ???????? <heckad at yandex.ru> added the comment:

How to make singleton class? I wrote this 

```
import asyncio


class Singleton:
    _CREATE_LOCK = asyncio.Lock()

    @classmethod
    async def create(cls):
        if not hasattr(cls, '_Singleton__instance'):
            async with cls._CREATE_LOCK:
                if not hasattr(cls, '_Singleton__instance'):
                    await asyncio.sleep(1)
                    cls.__instance = cls()
        return cls.__instance


async def main():
    await asyncio.wait([
        Singleton.create(),
        Singleton.create(),
    ])


if __name__ == '__main__':
    asyncio.run(main())
```

and got `RuntimeError`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39483>
_______________________________________

From report at bugs.python.org  Wed Jan 29 15:19:05 2020
From: report at bugs.python.org (CJ Long)
Date: Wed, 29 Jan 2020 20:19:05 +0000
Subject: [issue39490] Python Uninstaller fails to clean up the old path
 variables when uninstalling
Message-ID: <1580329145.11.0.630511319021.issue39490@roundup.psfhosted.org>


New submission from CJ Long <cjlong234 at gmail.com>:

I had Python 3.7 installed on my machine. However, I started having issues with it, so I uninstalled Python. However, when I reinstalled and attempted to run pip from Powershell, the old path was still in my variable, and therefore, could not run pip. Python still works.

----------
components: Installation
messages: 360984
nosy: brucelong
priority: normal
severity: normal
status: open
title: Python Uninstaller fails to clean up the old path variables when uninstalling
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39490>
_______________________________________

From report at bugs.python.org  Wed Jan 29 16:29:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 21:29:33 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580333373.26.0.157455576916.issue39489@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

As far as I known, the Fedora package of Python is the most known user of COUNT_ALLOCS special build, and maybe the only user.

The Fedora package of Python 2.7 builds two binaries:

* python2.7: release mode, optimized
* python2.7-debug: debug mode, not optimized, built with COUNT_ALLOCS defined

Sadly, in practice, python2.7-debug is basically unusable since C extensions providing by Fedora are not compatible: the release and the debug modes have a different ABI. I only fixed this recently in Python 3.8.

It uses COUNT_ALLOCS since the following patch (package version 2.6.5-10, in 2010) written by Dave Malcolm.


(1) There is a downstream patch adding --with-count-allocs flag to configure. Patch added to package version 2.6.5-10, in 2010:
https://src.fedoraproject.org/rpms/python2/c/ab11e4c10f6fef4e2e993ef446953df0f0dbb840


(2) Another downstream patch adds PYTHONDUMPCOUNTS environment variable to only dump statistics if the variable is set. Patch added to package version 2.7-8, in 2010:
https://src.fedoraproject.org/rpms/python2/c/5810c5d8b1c876ccc4c547cc71cf20520dd27d85

=> this patch was proposed upstream in bpo-19527. I merged it in Python 2.7.15 (in 2017), but with a different environment variable name: PYTHONSHOWALLOCCOUNT.


(3) Finally, a 3rd downstream patch fix test_abc when COUNT_ALLOCS is defined. Patch added to package version 2.7.1-1, in 2010:
https://src.fedoraproject.org/rpms/python2/c/4b97eebe22c8c5db58ae65cdc7e79c3ccd45b0a4

=> Bohuslav "Slavek" Kabrda created bpo-19527 to propose to make multiple test fixes upstream. Serhiy Storchaka modified the proposed patch by adding @test.support.requires_type_collecting decorator. Change merged in 3.5 and default branches, but not in 2.7.


Another example of Fedora contribution: bpo-31692 reports that test_regrtest fails when Python 2.7.14 is built with COUNT_ALLOCS.

---

Now, the interesting part.

IMHO COUNT_ALLOCS was basically kept between 2010 and 2015 because "it was there" and nobody asked if it still made sense to use it. It wasn't too expensive to maintain in the Fedora package... until someone asked if it's still worth it to maintain it in 2015.

The COUNT_ALLOCS macro has been removed from the Fedora package of Python 3 in 2015:

* https://bugzilla.redhat.com/show_bug.cgi?id=1291325
* "[cleanup] Remove COUNT_ALLOCS patches, see rhbz#1291325" commit:
  https://src.fedoraproject.org/rpms/python3/c/19aade22cbfa57dc500f5fa82229b4b9ed0b4c30

Extract of the bugzilla, "Reply from Dave Malcolm":
"""
My hazy recollection is that at the time I was dealing with lots of
memory leak issues in Python 2, so I was keen to add as much help as
possible in tracking them down to Python 2 and Python 3.

I don't think this patch ever really bought us much, and it sounds like
there are better tools for this now, so feel free to drop the
COUNT_ALLOC patches.
"""

It confirms what I wrote in the initial message of this issue: there are now better tool to track Python memory leaks.

Supporting COUNT_ALLOC in the Fedora package was motivated by Dave Malcolm use case of tracking memory leak, but even Dave wrote: "I don't think this patch ever really bought us much".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39489>
_______________________________________

From report at bugs.python.org  Wed Jan 29 16:31:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 21:31:14 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580333474.23.0.132304046963.issue39489@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Python 2.7.15 got a PYTHONSHOWALLOCCOUNT environment variable to dump statistics on types at exit, if Python is built with COUNT_ALLOCS macro defined.

Example with Fedora python2.7-debug (package python2-debug-2.7.17-1.fc31.x86_64):

$ PYTHONSHOWALLOCCOUNT=1 python2.7-debug -c pass
exceptions.ImportError alloc'd: 2, freed: 2, max in use: 1
symtable entry alloc'd: 3, freed: 3, max in use: 1
enumerate alloc'd: 2, freed: 2, max in use: 1
dict alloc'd: 459, freed: 220, max in use: 346
str alloc'd: 13981, freed: 12142, max in use: 5991
tuple alloc'd: 5088, freed: 4096, max in use: 2337
(...)
fast tuple allocs: 2434, empty: 1753
fast int allocs: pos: 875, neg: 74
null strings: 81, 1-strings: 328

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39489>
_______________________________________

From report at bugs.python.org  Wed Jan 29 16:40:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 21:40:00 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580334000.62.0.772281032037.issue39489@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I looked for "Python COUNT_ALLOCS" on the Internet. This special build seems to be very badly documented on the Internet. Outside Python own documentation, I found almost zero reference to it. IMHO it's basically unused.


(*) bpo-33058: Two years ago (2018), attempt to make COUNT_ALLOCS build ABI compatible with release build. Extract:

> > Could tracemalloc help you?
> tracemalloc can't distinguish between the usage of gc allocs, normal mallocs, and free list reuse.


(*) Documentation of all Python builds:

https://pythonextensionpatterns.readthedocs.io/en/latest/debugging/debug_python.html#debug-version-of-python-count-allocs-label

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39489>
_______________________________________

From report at bugs.python.org  Wed Jan 29 16:43:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 21:43:31 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580334211.04.0.389188421782.issue39489@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The COUNT_ALLOCS feature itself is quite old. It was added 27 years ago (in 1993):

commit a9c3c22c33762699b362e7598268442fd2df9eb6
Author: Sjoerd Mullender <sjoerd at acm.org>
Date:   Mon Oct 11 12:54:31 1993 +0000

    * Extended X interface: pixmap objects, colormap objects visual objects,
      image objects, and lots of new methods.
    * Added counting of allocations and deallocations of builtin types if
      COUNT_ALLOCS is defined.  Had to move calls to NEWREF down in some
      files.
    * Bug fix in sorting lists.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39489>
_______________________________________

From report at bugs.python.org  Wed Jan 29 16:46:08 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Wed, 29 Jan 2020 21:46:08 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
Message-ID: <1580334368.43.0.748250162443.issue39491@roundup.psfhosted.org>


Change by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
components: Library (Lib)
nosy: jstasiak
priority: normal
severity: normal
status: open
title: Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39491>
_______________________________________

From report at bugs.python.org  Wed Jan 29 16:59:55 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Wed, 29 Jan 2020 21:59:55 +0000
Subject: [issue39491] Import PEP 593 (Flexible function and variable
 annotations) support already implemented in typing_extensions
Message-ID: <1580335195.94.0.874184836755.issue39491@roundup.psfhosted.org>


Change by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
keywords: +patch
pull_requests: +17636
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18260

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39491>
_______________________________________

From report at bugs.python.org  Wed Jan 29 17:23:55 2020
From: report at bugs.python.org (Tim Peters)
Date: Wed, 29 Jan 2020 22:23:55 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580336635.77.0.61037581081.issue39479@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

+0 from me.

Another use is computing the Carmichael function for composite numbers (like an RSA encryption modulus, in which context the Carmichael function is routinely used).

But only +0 instead of +1 because it's so easy to build from gcd().

I don't agree it's tricky at all.  While lcm(0, 0) undoubtedly should return 0 in a general-purpose library function, in my own code I've never supplied that.  Because in every application I've ever had for it, I would rather get an exception if I ever passed two zeroes - that would always have been a mistake.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Wed Jan 29 17:46:21 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Jan 2020 22:46:21 +0000
Subject: [issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code
In-Reply-To: <1580309528.55.0.307294388242.issue39487@roundup.psfhosted.org>
Message-ID: <1580337981.51.0.384688387562.issue39487@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

We can't make this change, as it means the statics get initialised before the Python interpreter has been initialised, and won't be reinitialised if the interpreter is destroyed and recreated.

----------
nosy: +ncoghlan
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39487>
_______________________________________

From report at bugs.python.org  Wed Jan 29 17:53:37 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Jan 2020 22:53:37 +0000
Subject: [issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code
In-Reply-To: <1580309528.55.0.307294388242.issue39487@roundup.psfhosted.org>
Message-ID: <1580338417.91.0.23335246756.issue39487@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

My apologies, my comment above was based on an outdated understanding of how the identifier structs get initialised (it's the usage that initialises them, not the declaration).

That means this is a useful refactoring to help identify blockers to full subinterpreter support.

----------
resolution: rejected -> 
stage: resolved -> patch review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39487>
_______________________________________

From report at bugs.python.org  Wed Jan 29 17:58:29 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 29 Jan 2020 22:58:29 +0000
Subject: [issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code
In-Reply-To: <1580309528.55.0.307294388242.issue39487@roundup.psfhosted.org>
Message-ID: <1580338709.75.0.567880883024.issue39487@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

In the subinterpreter context: perhaps it would make sense to move *all* Py_IDENTIFIER declarations to file scope?

That would make it much clearer which of our extension modules actually have hidden state for caching purposes.

If we did that though, we'd also want to update the usage instructions in object.h

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39487>
_______________________________________

From report at bugs.python.org  Wed Jan 29 18:08:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 23:08:00 +0000
Subject: [issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code
In-Reply-To: <1580309528.55.0.307294388242.issue39487@roundup.psfhosted.org>
Message-ID: <1580339280.96.0.81606549661.issue39487@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> That means this is a useful refactoring to help identify blockers to full subinterpreter support.

I don't think that subinterpreter support should block this issue, since currently, _Py_IDENTIFIER() does *not* support subinterpreters.

> In the subinterpreter context: perhaps it would make sense to move *all* Py_IDENTIFIER declarations to file scope?

What do you mean? _Py_IDENTIFIER() macro uses "static", so no identifier is visible outside the current C file. The scope may be the whole file, or the current function, depending where it's declared.

--

Once I discussed with Eric: _Py_IDENTIFIER() should use an "interpreter local storage" for identifiers values. _Py_IDENTIFIER() would only be a "key" and _PyUnicode_FromId() would store the value somewhere in a hash table stored in PyInterpreterState. Something similar to the TSS API:

* PyThread_create_key()
* PyThread_delete_key_value()
* PyThread_set_key_value()
* PyThread_get_key_value()

But per interpreter, rather than being per thread.

The key can be simply the variable address in memory. It only has to be unique in the process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39487>
_______________________________________

From report at bugs.python.org  Wed Jan 29 18:15:06 2020
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 29 Jan 2020 23:15:06 +0000
Subject: [issue39488] test_largefile: TestSocketSendfile.test_it() uses too
 much disk space
In-Reply-To: <1580318049.66.0.254124049267.issue39488@roundup.psfhosted.org>
Message-ID: <1580339706.69.0.177337819078.issue39488@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
keywords: +patch
pull_requests: +17637
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18261

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39488>
_______________________________________

From report at bugs.python.org  Wed Jan 29 18:30:26 2020
From: report at bugs.python.org (Jeremy Kloth)
Date: Wed, 29 Jan 2020 23:30:26 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580340626.37.0.20716388028.issue39401@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

As noted on the PR landing page, this PR has caused failures of 2 buildbots:

https://buildbot.python.org/all/#builders/81/builds/272

https://buildbot.python.org/all/#builders/150/builds/227

(both are Windows 7)

----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Wed Jan 29 18:36:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 23:36:26 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580340986.88.0.279991393235.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17638
pull_request: https://github.com/python/cpython/pull/18258

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Wed Jan 29 18:39:28 2020
From: report at bugs.python.org (Pierre Glaser)
Date: Wed, 29 Jan 2020 23:39:28 +0000
Subject: [issue39492] reference cycle affecting Pickler instances (Python3.8+)
Message-ID: <1580341168.06.0.481762102037.issue39492@roundup.psfhosted.org>


New submission from Pierre Glaser <pierreglaser at msn.com>:

The new Pickler reducer_override mechanism introduced in `Python3.8` generates a reference cycle: for optimization purposes, a the pickler.reducer_override bound method is referenced into the reducer_override attribute of the Pickler's struct. Thus, until as a gc.collect call is performed, both the Pickler and all the elements it pickled (as they are part of its memo), wont be collected.

We should break this cycle a the end of the dump() method.

See reproducer below:
```
import threading
import weakref
import pickle
import io


class MyClass:
    pass


my_object = MyClass()
collect = threading.Event()
_ = weakref.ref(my_object, lambda obj: collect.set())  # noqa


class MyPickler(pickle.Pickler):
    def reducer_override(self, obj):
        return NotImplemented


my_pickler = MyPickler(io.BytesIO())
my_pickler.dump(my_object)
del my_object
del my_pickler

# import gc
# gc.collect()

for i in range(5):
    collected = collect.wait(timeout=0.1)
    if collected:
        print('my_object was successfully collected')
        break
```

----------
components: Library (Lib)
messages: 360995
nosy: pierreglaser, pitrou
priority: normal
severity: normal
status: open
title: reference cycle affecting Pickler instances (Python3.8+)
type: resource usage
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39492>
_______________________________________

From report at bugs.python.org  Wed Jan 29 18:41:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 23:41:16 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580341276.24.0.434782629596.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17639
pull_request: https://github.com/python/cpython/pull/18262

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Wed Jan 29 18:54:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 29 Jan 2020 23:54:53 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580342093.44.0.963426215885.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17640
pull_request: https://github.com/python/cpython/pull/18263

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Wed Jan 29 19:37:08 2020
From: report at bugs.python.org (Shantanu)
Date: Thu, 30 Jan 2020 00:37:08 +0000
Subject: [issue39493] typing.py has an incorrect definition of closed
Message-ID: <1580344628.01.0.169235800927.issue39493@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

Hello!

typing.py has the following definition of `closed`:
https://github.com/python/cpython/blob/master/Lib/typing.py#L1834
```
    @abstractmethod
    def closed(self) -> bool:
        pass
```

This is inconsistent with the behaviour at runtime:
```
In [17]: sys.version                                                                                                  
Out[17]: '3.8.1 (default, Jan 23 2020, 23:36:06) \n[Clang 11.0.0 (clang-1100.0.33.17)]'

In [18]: f = open("test", "w")                                                                                        

In [19]: f.closed                                                                                                     
Out[19]: False
```

It seems like the right thing to do is add an @property, as we do with e.g. `mode` and `name`. I'll submit a PR with this change.

Note typeshed also types this as a property to indicate a read-only attribute.
https://github.com/python/typeshed/blob/master/stdlib/3/typing.pyi#L459

First time filing a bug on BPO, thanks a lot in advance!

----------
messages: 360996
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: typing.py has an incorrect definition of closed
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39493>
_______________________________________

From report at bugs.python.org  Wed Jan 29 19:41:07 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 30 Jan 2020 00:41:07 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580344867.33.0.961170917345.issue39401@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Both of those buildbots should be retired (or repurposed for versions of Python that still support Windows 7) :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Wed Jan 29 19:41:47 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 30 Jan 2020 00:41:47 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580344907.4.0.750214850403.issue39401@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> this PR has caused failures of 2 buildbots

The master branch should no longer get built on Windows 7 machines. The initial build succeeds, but running "_freeze_importlib[_d].exe" fails with STATUS_DLL_NOT_FOUND (0xC0000135, i.e. -1073741515) since "api-ms-win-core-path-l1-1-0.dll" (linked from pathcch.lib) is not a Windows 7 API set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Wed Jan 29 19:42:41 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 30 Jan 2020 00:42:41 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580344961.04.0.833987611632.issue39401@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I added https://python-security.readthedocs.io/vuln/unsafe-dll-load-windows-7.html to track fixes in all branches.

Thanks, Victor!

Python 2.7 and 3.5 are not vulnerable. The issue was added in 3.6 when I added support for installing Python into a long path name on up-to-date OS, which required dynamically loading an OS function. That dynamic load was the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Wed Jan 29 20:03:06 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 30 Jan 2020 01:03:06 +0000
Subject: [issue39320] Handle unpacking of */** arguments and rvalues in the
 compiler
In-Reply-To: <1578918490.54.0.342025462897.issue39320@roundup.psfhosted.org>
Message-ID: <1580346186.0.0.907649053127.issue39320@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +17641
pull_request: https://github.com/python/cpython/pull/18264

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39320>
_______________________________________

From report at bugs.python.org  Wed Jan 29 20:09:38 2020
From: report at bugs.python.org (Shantanu)
Date: Thu, 30 Jan 2020 01:09:38 +0000
Subject: [issue39493] typing.py has an incorrect definition of closed
In-Reply-To: <1580344628.01.0.169235800927.issue39493@roundup.psfhosted.org>
Message-ID: <1580346578.38.0.221696397118.issue39493@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
keywords: +patch
pull_requests: +17642
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18265

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39493>
_______________________________________

From report at bugs.python.org  Wed Jan 29 20:13:13 2020
From: report at bugs.python.org (Pierre Glaser)
Date: Thu, 30 Jan 2020 01:13:13 +0000
Subject: [issue39492] reference cycle affecting Pickler instances (Python3.8+)
In-Reply-To: <1580341168.06.0.481762102037.issue39492@roundup.psfhosted.org>
Message-ID: <1580346793.96.0.287468391739.issue39492@roundup.psfhosted.org>


Change by Pierre Glaser <pierreglaser at msn.com>:


----------
keywords: +patch
pull_requests: +17643
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18266

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39492>
_______________________________________

From report at bugs.python.org  Wed Jan 29 20:28:58 2020
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 30 Jan 2020 01:28:58 +0000
Subject: [issue33339] Using default encoding with `subprocess.run()` is not
 obvious
In-Reply-To: <1524472712.16.0.682650639539.issue33339@psf.upfronthosting.co.za>
Message-ID: <1580347738.27.0.786000922477.issue33339@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

This issue was already addressed for 3.x in bpo-31756, which added the a `text` parameter and updated the documentation. As to 2.7, it was officially retired as of the first of this month. Anyway, I don't think there was a pressing need to clarify the documentation in 2.7.

----------
nosy: +eryksun
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> subprocess.run should alias universal_newlines to text

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33339>
_______________________________________

From report at bugs.python.org  Wed Jan 29 20:43:52 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 30 Jan 2020 01:43:52 +0000
Subject: [issue39494] Extra null terminators in keyword arrays in sqlite module
Message-ID: <1580348632.36.0.607657173065.issue39494@roundup.psfhosted.org>


New submission from Alex Henrie <alexhenrie24 at gmail.com>:

Modules/_sqlite/cursor.c currently has the following variable declaration:

    static char *kwlist[] = {"size", NULL, NULL};

The second null terminator is unnecessary and detrimental in that it makes the code harder to read and understand.

Modules/_sqlite/module.c has two additional kwlist variables with the same problem.

----------
components: Library (Lib)
messages: 361001
nosy: alex.henrie
priority: normal
severity: normal
status: open
title: Extra null terminators in keyword arrays in sqlite module
type: resource usage
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39494>
_______________________________________

From report at bugs.python.org  Wed Jan 29 20:46:51 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 30 Jan 2020 01:46:51 +0000
Subject: [issue39494] Extra null terminators in keyword arrays in sqlite module
In-Reply-To: <1580348632.36.0.607657173065.issue39494@roundup.psfhosted.org>
Message-ID: <1580348811.06.0.0279125563636.issue39494@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
keywords: +patch
pull_requests: +17644
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18267

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39494>
_______________________________________

From report at bugs.python.org  Wed Jan 29 21:11:47 2020
From: report at bugs.python.org (Shantanu)
Date: Thu, 30 Jan 2020 02:11:47 +0000
Subject: [issue39495] xml.etree.ElementTree.TreeBuilder.start differs between
 pure Python and C implementations
Message-ID: <1580350307.52.0.118414531826.issue39495@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

The C accelerated version of `xml.etree.ElementTree.TreeBuilder.start` has a default value for `attrs`, whereas the pure Python version does not.

```
In [41]: sys.version                                                                                                               
Out[41]: '3.8.1 (default, Jan 23 2020, 23:36:06) \n[Clang 11.0.0 (clang-1100.0.33.17)]'

In [42]: import xml.etree.ElementTree                                                                                              

In [43]: inspect.signature(xml.etree.ElementTree.TreeBuilder.start)                                                                
Out[43]: <Signature (self, tag, attrs=None, /)>

In [44]: from test.support import import_fresh_module                                                                              

In [45]: pyElementTree = import_fresh_module('xml.etree.ElementTree', blocked=['_elementtree'])                                    

In [46]: inspect.signature(pyElementTree.TreeBuilder.start)                                                                        
Out[46]: <Signature (self, tag, attrs)>
```

>From PEP 399 (https://www.python.org/dev/peps/pep-0399/)
```
Acting as a drop-in replacement also dictates that no public API be provided in accelerated code that does not exist in the pure Python code. Without this requirement people could accidentally come to rely on a detail in the accelerated code which is not made available to other VMs that use the pure Python implementation. 
```

----------
components: Library (Lib)
messages: 361002
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree.TreeBuilder.start differs between pure Python and C implementations

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39495>
_______________________________________

From report at bugs.python.org  Wed Jan 29 21:37:34 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 30 Jan 2020 02:37:34 +0000
Subject: [issue38792] IDLE calltips may not properly close on KeyboardInterrupt
In-Reply-To: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>
Message-ID: <1580351854.84.0.400722878888.issue38792@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I verified problem for KeyboardInterrupt and RestartShell but not for a newline that actually runs the statement.  In my experiments, if a newline in inserted instead of running, the cursor remains within a call and the calltip should not disappear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38792>
_______________________________________

From report at bugs.python.org  Wed Jan 29 21:52:40 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Jan 2020 02:52:40 +0000
Subject: [issue39493] typing.py has an incorrect definition of closed
In-Reply-To: <1580344628.01.0.169235800927.issue39493@roundup.psfhosted.org>
Message-ID: <1580352760.43.0.716097402607.issue39493@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 2e6569b6692298fcc9aae0df3eb3181adb2a5099 by Shantanu in branch 'master':
bpo-39493: Fix definition of IO.closed in typing.py (#18265)
https://github.com/python/cpython/commit/2e6569b6692298fcc9aae0df3eb3181adb2a5099


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39493>
_______________________________________

From report at bugs.python.org  Wed Jan 29 21:56:54 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 30 Jan 2020 02:56:54 +0000
Subject: [issue39495] xml.etree.ElementTree.TreeBuilder.start differs between
 pure Python and C implementations
In-Reply-To: <1580350307.52.0.118414531826.issue39495@roundup.psfhosted.org>
Message-ID: <1580353014.86.0.822424188805.issue39495@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eli.bendersky, scoder, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39495>
_______________________________________

From report at bugs.python.org  Wed Jan 29 22:05:24 2020
From: report at bugs.python.org (Shantanu)
Date: Thu, 30 Jan 2020 03:05:24 +0000
Subject: [issue39495] xml.etree.ElementTree.TreeBuilder.start differs between
 pure Python and C implementations
In-Reply-To: <1580350307.52.0.118414531826.issue39495@roundup.psfhosted.org>
Message-ID: <1580353524.86.0.600581647564.issue39495@roundup.psfhosted.org>


Shantanu <hauntsaninja at gmail.com> added the comment:

Based on https://github.com/python/cpython/blob/master/Modules/_elementtree.c#L2700 and the behaviour at runtime, something like the following patch could work:
```
diff --git a/Lib/xml/etree/ElementTree.py b/Lib/xml/etree/ElementTree.py
index c8d898f328..bbfc1afe08 100644
--- a/Lib/xml/etree/ElementTree.py
+++ b/Lib/xml/etree/ElementTree.py
@@ -1452,7 +1452,7 @@ class TreeBuilder:
         """Add text to current element."""
         self._data.append(data)
 
-    def start(self, tag, attrs):
+    def start(self, tag, attrs=None):
         """Open new element and return it.
 
         *tag* is the element name, *attrs* is a dict containing element
@@ -1460,6 +1460,8 @@ class TreeBuilder:
 
         """
         self._flush()
+        if attrs is None:
+            attrs = {}
         self._last = elem = self._factory(tag, attrs)
         if self._elem:
             self._elem[-1].append(elem)
```

Happy to submit a PR!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39495>
_______________________________________

From report at bugs.python.org  Wed Jan 29 22:18:40 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 30 Jan 2020 03:18:40 +0000
Subject: [issue39496] Inelegant loops in Modules/_sqlite/cursor.c
Message-ID: <1580354320.44.0.87062873054.issue39496@roundup.psfhosted.org>


New submission from Alex Henrie <alexhenrie24 at gmail.com>:

pysqlite_cursor_fetchall currently has the following bit of code:

    /* just make sure we enter the loop */
    row = (PyObject*)Py_None;

    while (row) {
        row = pysqlite_cursor_iternext(self);
        if (row) {
            PyList_Append(list, row);
            Py_DECREF(row);
        }
    }

This can and should be rewritten as a for loop to avoid the unnecessary initialization to Py_None and the redundant if statement inside the loop.

pysqlite_cursor_fetchmany has the same problem.

----------
components: Library (Lib)
messages: 361006
nosy: alex.henrie
priority: normal
severity: normal
status: open
title: Inelegant loops in Modules/_sqlite/cursor.c
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39496>
_______________________________________

From report at bugs.python.org  Wed Jan 29 22:21:22 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 30 Jan 2020 03:21:22 +0000
Subject: [issue39496] Inelegant loops in Modules/_sqlite/cursor.c
In-Reply-To: <1580354320.44.0.87062873054.issue39496@roundup.psfhosted.org>
Message-ID: <1580354482.09.0.361147568659.issue39496@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
keywords: +patch
pull_requests: +17645
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18270

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39496>
_______________________________________

From report at bugs.python.org  Wed Jan 29 23:12:56 2020
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 30 Jan 2020 04:12:56 +0000
Subject: [issue39494] Extra null terminators in keyword arrays in sqlite module
In-Reply-To: <1580348632.36.0.607657173065.issue39494@roundup.psfhosted.org>
Message-ID: <1580357576.85.0.659458423125.issue39494@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 188bb5b1e868eecf2342195dc45caa332ac3b6c7 by Alex Henrie in branch 'master':
bpo-39494: Remove extra null terminators from kwlist vars (GH-18267)
https://github.com/python/cpython/commit/188bb5b1e868eecf2342195dc45caa332ac3b6c7


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39494>
_______________________________________

From report at bugs.python.org  Wed Jan 29 23:13:32 2020
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 30 Jan 2020 04:13:32 +0000
Subject: [issue39494] Extra null terminators in keyword arrays in sqlite module
In-Reply-To: <1580348632.36.0.607657173065.issue39494@roundup.psfhosted.org>
Message-ID: <1580357612.23.0.909253995155.issue39494@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: resource usage -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39494>
_______________________________________

From report at bugs.python.org  Wed Jan 29 23:19:16 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 30 Jan 2020 04:19:16 +0000
Subject: [issue39497] Unused variable script_str in
 pysqlite_cursor_executescript
Message-ID: <1580357955.97.0.537280563038.issue39497@roundup.psfhosted.org>


New submission from Alex Henrie <alexhenrie24 at gmail.com>:

The function pysqlite_cursor_executescript defines a variable called script_str, initializes it to NULL, and calls Py_XDECREF on it. However, this variable has been unused since August 2007: https://github.com/python/cpython/commit/6d21456137836b8acd551cf6a51999ad4ff10a91#diff-26f74db3527991715b482a5ed2603870L752

----------
components: Library (Lib)
messages: 361008
nosy: alex.henrie
priority: normal
severity: normal
status: open
title: Unused variable script_str in pysqlite_cursor_executescript
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39497>
_______________________________________

From report at bugs.python.org  Wed Jan 29 23:21:40 2020
From: report at bugs.python.org (Alex Henrie)
Date: Thu, 30 Jan 2020 04:21:40 +0000
Subject: [issue39497] Unused variable script_str in
 pysqlite_cursor_executescript
In-Reply-To: <1580357955.97.0.537280563038.issue39497@roundup.psfhosted.org>
Message-ID: <1580358100.3.0.467045404342.issue39497@roundup.psfhosted.org>


Change by Alex Henrie <alexhenrie24 at gmail.com>:


----------
keywords: +patch
pull_requests: +17646
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18271

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39497>
_______________________________________

From report at bugs.python.org  Thu Jan 30 00:14:32 2020
From: report at bugs.python.org (anthony shaw)
Date: Thu, 30 Jan 2020 05:14:32 +0000
Subject: [issue39498] Signpost security considerations in library
Message-ID: <1580361272.17.0.099312904306.issue39498@roundup.psfhosted.org>


New submission from anthony shaw <anthonyshaw at apache.org>:

Within the documentation, there are some really important security considerations for standard library modules. e.g. subprocess, ssl, pickle, xml.

There is currently no "index" of these, so you have to go hunting for them. They're easter eggs within the docs. There isn't a unique admonition type either, so you have to search across many criteria.

In particular for security researchers, it would be useful to consolidate and signpost these security best-practices in one index.

PR to follow,

----------
assignee: docs at python
components: Documentation
messages: 361009
nosy: anthonypjshaw, docs at python
priority: normal
severity: normal
status: open
title: Signpost security considerations in library
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39498>
_______________________________________

From report at bugs.python.org  Thu Jan 30 00:15:42 2020
From: report at bugs.python.org (anthony shaw)
Date: Thu, 30 Jan 2020 05:15:42 +0000
Subject: [issue39498] Signpost security considerations in library
In-Reply-To: <1580361272.17.0.099312904306.issue39498@roundup.psfhosted.org>
Message-ID: <1580361342.57.0.643706497366.issue39498@roundup.psfhosted.org>


Change by anthony shaw <anthonyshaw at apache.org>:


----------
keywords: +patch
pull_requests: +17647
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18272

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39498>
_______________________________________

From report at bugs.python.org  Thu Jan 30 00:22:58 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Jan 2020 05:22:58 +0000
Subject: [issue39493] typing.py has an incorrect definition of closed
In-Reply-To: <1580344628.01.0.169235800927.issue39493@roundup.psfhosted.org>
Message-ID: <1580361778.92.0.894453775705.issue39493@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17648
pull_request: https://github.com/python/cpython/pull/18273

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39493>
_______________________________________

From report at bugs.python.org  Thu Jan 30 00:23:05 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Jan 2020 05:23:05 +0000
Subject: [issue39493] typing.py has an incorrect definition of closed
In-Reply-To: <1580344628.01.0.169235800927.issue39493@roundup.psfhosted.org>
Message-ID: <1580361785.92.0.83868854922.issue39493@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17649
pull_request: https://github.com/python/cpython/pull/18274

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39493>
_______________________________________

From report at bugs.python.org  Thu Jan 30 00:42:42 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Jan 2020 05:42:42 +0000
Subject: [issue39493] typing.py has an incorrect definition of closed
In-Reply-To: <1580344628.01.0.169235800927.issue39493@roundup.psfhosted.org>
Message-ID: <1580362962.52.0.308388577338.issue39493@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 58076df0c59677111dc77b72852cb2a313a2ef91 by Miss Islington (bot) in branch '3.8':
bpo-39493: Fix definition of IO.closed in typing.py (GH-18265)
https://github.com/python/cpython/commit/58076df0c59677111dc77b72852cb2a313a2ef91


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39493>
_______________________________________

From report at bugs.python.org  Thu Jan 30 01:00:16 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Jan 2020 06:00:16 +0000
Subject: [issue39493] typing.py has an incorrect definition of closed
In-Reply-To: <1580344628.01.0.169235800927.issue39493@roundup.psfhosted.org>
Message-ID: <1580364016.02.0.856196849558.issue39493@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 194c7aeb6f3d6c2b0015457d22b38253652f4f38 by Miss Islington (bot) in branch '3.7':
[3.7] bpo-39493: Fix definition of IO.closed in typing.py (GH-18273)
https://github.com/python/cpython/commit/194c7aeb6f3d6c2b0015457d22b38253652f4f38


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39493>
_______________________________________

From report at bugs.python.org  Thu Jan 30 01:00:37 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Jan 2020 06:00:37 +0000
Subject: [issue39493] typing.py has an incorrect definition of closed
In-Reply-To: <1580344628.01.0.169235800927.issue39493@roundup.psfhosted.org>
Message-ID: <1580364037.45.0.107802403325.issue39493@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks, Shantanu!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39493>
_______________________________________

From report at bugs.python.org  Thu Jan 30 01:07:21 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Jan 2020 06:07:21 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580364441.2.0.00943084080507.issue39401@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 561c59777c8426fde0ef48b57cf02eddaeb2a5b8 by Steve Dower in branch '3.7':
[3.7] bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier (GH-18231) (GH-18232)
https://github.com/python/cpython/commit/561c59777c8426fde0ef48b57cf02eddaeb2a5b8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Thu Jan 30 01:18:33 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Jan 2020 06:18:33 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580365113.87.0.833932218152.issue39401@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ad4a20b87d79a619ffbdea3f26848780899494e5 by Steve Dower in branch '3.8':
[3.8] bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier (GH-18231) (GH-18234)
https://github.com/python/cpython/commit/ad4a20b87d79a619ffbdea3f26848780899494e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Thu Jan 30 01:32:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Jan 2020 06:32:32 +0000
Subject: [issue39495] xml.etree.ElementTree.TreeBuilder.start differs between
 pure Python and C implementations
In-Reply-To: <1580350307.52.0.118414531826.issue39495@roundup.psfhosted.org>
Message-ID: <1580365952.32.0.982873373961.issue39495@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

According to the documentation the attrs parameter does not have default value. I think that the C implementation should be changed.

https://docs.python.org/3/library/xml.etree.elementtree.html#xml.etree.ElementTree.TreeBuilder.start

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39495>
_______________________________________

From report at bugs.python.org  Thu Jan 30 01:49:37 2020
From: report at bugs.python.org (Shantanu)
Date: Thu, 30 Jan 2020 06:49:37 +0000
Subject: [issue39495] xml.etree.ElementTree.TreeBuilder.start differs between
 pure Python and C implementations
In-Reply-To: <1580350307.52.0.118414531826.issue39495@roundup.psfhosted.org>
Message-ID: <1580366977.44.0.709159524388.issue39495@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
keywords: +patch
pull_requests: +17650
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18275

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39495>
_______________________________________

From report at bugs.python.org  Thu Jan 30 02:41:48 2020
From: report at bugs.python.org (Oscar)
Date: Thu, 30 Jan 2020 07:41:48 +0000
Subject: [issue39499] ValueError using index on tuple is not showing the tuple
 value
Message-ID: <1580370108.47.0.271074829024.issue39499@roundup.psfhosted.org>


New submission from Oscar <tuxskar at gmail.com>:

When trying to retrieve the index of an element that is not in a tuple the error message of ValueError is not showing the value looking for but instead a static message tuple.index(x): x not in tuple

>>> b = (1, 2, 3, 4)
>>> b.index(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: tuple.index(x): x not in tuple

I would expect something like what happen in lists where the element (5 in this case) is showed on the ValueError.
>>> a = [1, 2, 3, 4]
>>> a.index(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: 5 is not in list

----------
messages: 361016
nosy: tuxskar
priority: normal
severity: normal
status: open
title: ValueError using index on tuple is not showing the tuple value
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39499>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:01:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 08:01:22 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580371282.46.0.476620866897.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 5eb8bff7e4aa7e4d8580a30323641388c8ff59a5 by Victor Stinner in branch 'master':
bpo-38631: Replace Py_FatalError() with _PyObject_ASSERT_FAILED_MSG() (GH-18258)
https://github.com/python/cpython/commit/5eb8bff7e4aa7e4d8580a30323641388c8ff59a5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:02:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 08:02:20 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580371340.57.0.530286509922.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7a1f6c2da46a04d0ff0acc01542f30bfeaf0e0c7 by Victor Stinner in branch 'master':
bpo-38631: Avoid Py_FatalError() in init_slotdefs() (GH-18263)
https://github.com/python/cpython/commit/7a1f6c2da46a04d0ff0acc01542f30bfeaf0e0c7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:02:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 08:02:55 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580371375.86.0.604228220676.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 2bf127d97bd1d60ead7c20d429b0c61ef61fc554 by Victor Stinner in branch 'master':
bpo-38631: Replace tp_new_wrapper() fatal error with SystemError (GH-18262)
https://github.com/python/cpython/commit/2bf127d97bd1d60ead7c20d429b0c61ef61fc554


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:07:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 08:07:53 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1580371673.5.0.549349679536.issue39353@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17651
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/18276

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:09:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 08:09:19 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1580371759.69.0.733810889196.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Of course I would prefer ?crc_hqx? to stay, because we use it at work.

I propose to deprecate it because I understood that it was strictly related to binhex4 and hexbin4 protocols. If there is an use case outside these protocols, I'm fine with maintaining it.

The first motivation was to drop the binhex module in the long term, I'm less worried about specific binascii functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:16:58 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Jan 2020 08:16:58 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580372218.91.0.6726719419.issue39479@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

+0 from me as well; agreed with everything that Tim said (except that I've never had a need for the Carmichael function; my RSA implementations do the inefficient thing based on (p-1)(q-1)).

This is somewhat reminiscent of comb and perm: lcm is often taught as a natural counterpart to gcd, so despite the fact that it's less fundamental and has less utility, people often expect to see the two together.

@Ananthakrishnan: do you want to put together a PR? I'll commit to reviewing it if you do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:28:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 08:28:35 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580372915.92.0.533357081893.issue39401@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

>> I added https://python-security.readthedocs.io/vuln/unsafe-dll-load-windows-7.html to track fixes in all branches.

> Thanks, Victor! Python 2.7 and 3.5 are not vulnerable. The issue was added in 3.6 when I added support for installing Python into a long path name on up-to-date OS, which required dynamically loading an OS function. That dynamic load was the problem.

Oh ok, I updated the page to reflect that. I also added 3.7 & 3.8 commits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:47:39 2020
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 30 Jan 2020 08:47:39 +0000
Subject: [issue39424] [easy] test_signal: test_pidfd_send_signal() uses
 deprecated assertRaisesRegexp() method
In-Reply-To: <1579712181.32.0.0974422649306.issue39424@roundup.psfhosted.org>
Message-ID: <1580374059.03.0.0195251931662.issue39424@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +17652
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18277

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39424>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:48:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 08:48:20 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580374100.02.0.7065204485.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17653
pull_request: https://github.com/python/cpython/pull/18278

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:56:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 08:56:44 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1580374604.07.0.905611952989.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset c38fd0df2b4cbc1cc906d8dfe23f63b67cd6965f by Victor Stinner in branch 'master':
bpo-39353: binascii.crc_hqx() is no longer deprecated (GH-18276)
https://github.com/python/cpython/commit/c38fd0df2b4cbc1cc906d8dfe23f63b67cd6965f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:57:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 08:57:13 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1580374633.61.0.641909089911.issue39353@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

binascii.crc_hqx() is no longer deprecated. I close again the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Thu Jan 30 03:57:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 08:57:55 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580374675.67.0.793476103328.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17654
pull_request: https://github.com/python/cpython/pull/18279

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Thu Jan 30 04:03:41 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 30 Jan 2020 09:03:41 +0000
Subject: [issue39499] ValueError using index on tuple is not showing the tuple
 value
In-Reply-To: <1580370108.47.0.271074829024.issue39499@roundup.psfhosted.org>
Message-ID: <1580375021.76.0.7568902465.issue39499@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This is a duplicate of issue33560. See also issue13349 which is the original duplicate.

----------
nosy: +xtreak
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Non-informative error message in index() and remove() functions
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39499>
_______________________________________

From report at bugs.python.org  Thu Jan 30 04:18:28 2020
From: report at bugs.python.org (Gabriel Tardif)
Date: Thu, 30 Jan 2020 09:18:28 +0000
Subject: [issue39458] Multiprocessing.Pool maxtasksperchild=1 doesn't work
In-Reply-To: <1580077815.77.0.653421680761.issue39458@roundup.psfhosted.org>
Message-ID: <1580375908.87.0.730757305639.issue39458@roundup.psfhosted.org>


Gabriel Tardif <gabriel at zeroinfo.tech> added the comment:

Be aware that maxtasksperchild work together with the chunksize parameter of the map fonction when you use it and the default chunksize value is not 1, it's calculated according to your inputs, process and other parameters.

----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39458>
_______________________________________

From report at bugs.python.org  Thu Jan 30 04:18:37 2020
From: report at bugs.python.org (Gabriel Tardif)
Date: Thu, 30 Jan 2020 09:18:37 +0000
Subject: [issue39458] Multiprocessing.Pool maxtasksperchild=1 doesn't work
In-Reply-To: <1580077815.77.0.653421680761.issue39458@roundup.psfhosted.org>
Message-ID: <1580375917.64.0.631271008969.issue39458@roundup.psfhosted.org>


Change by Gabriel Tardif <gabriel at zeroinfo.tech>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39458>
_______________________________________

From report at bugs.python.org  Thu Jan 30 04:22:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 09:22:35 +0000
Subject: [issue39500] Document PyUnicode_IsIdentifier() function
Message-ID: <1580376155.12.0.83956121235.issue39500@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The PyUnicode_IsIdentifier() function should be documented.

Attachd PR documents it.

----------
components: C API, Unicode
messages: 361027
nosy: ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Document PyUnicode_IsIdentifier() function
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39500>
_______________________________________

From report at bugs.python.org  Thu Jan 30 04:26:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 09:26:06 +0000
Subject: [issue39500] Document PyUnicode_IsIdentifier() function
In-Reply-To: <1580376155.12.0.83956121235.issue39500@roundup.psfhosted.org>
Message-ID: <1580376366.59.0.784178901108.issue39500@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17655
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18280

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39500>
_______________________________________

From report at bugs.python.org  Thu Jan 30 04:32:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 09:32:27 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580376747.8.0.806446597234.issue38631@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17656
pull_request: https://github.com/python/cpython/pull/18281

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Thu Jan 30 04:39:32 2020
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 30 Jan 2020 09:39:32 +0000
Subject: [issue39497] Unused variable script_str in
 pysqlite_cursor_executescript
In-Reply-To: <1580357955.97.0.537280563038.issue39497@roundup.psfhosted.org>
Message-ID: <1580377172.29.0.89962311269.issue39497@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:


New changeset 1f44e775df8e7ec3ca60a1135cb3279f8b9dca3e by Alex Henrie in branch 'master':
bpo-39497: Remove unused variable from pysqlite_cursor_executescript (GH-18271)
https://github.com/python/cpython/commit/1f44e775df8e7ec3ca60a1135cb3279f8b9dca3e


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39497>
_______________________________________

From report at bugs.python.org  Thu Jan 30 04:39:47 2020
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 30 Jan 2020 09:39:47 +0000
Subject: [issue39497] Unused variable script_str in
 pysqlite_cursor_executescript
In-Reply-To: <1580357955.97.0.537280563038.issue39497@roundup.psfhosted.org>
Message-ID: <1580377187.89.0.442588547012.issue39497@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: performance -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39497>
_______________________________________

From report at bugs.python.org  Thu Jan 30 05:04:27 2020
From: report at bugs.python.org (Ananthakrishnan A S)
Date: Thu, 30 Jan 2020 10:04:27 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580378667.76.0.145983746722.issue39479@roundup.psfhosted.org>


Ananthakrishnan A S <ananthakrishnan15.2001 at gmail.com> added the comment:

Yes,I want to put together a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Thu Jan 30 05:06:47 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 30 Jan 2020 10:06:47 +0000
Subject: [issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code
In-Reply-To: <1580309528.55.0.307294388242.issue39487@roundup.psfhosted.org>
Message-ID: <1580378807.73.0.921148438277.issue39487@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

If i understand clearly, msg360993 is an solution of issue39465.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39487>
_______________________________________

From report at bugs.python.org  Thu Jan 30 05:13:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Jan 2020 10:13:55 +0000
Subject: [issue39500] Document PyUnicode_IsIdentifier() function
In-Reply-To: <1580376155.12.0.83956121235.issue39500@roundup.psfhosted.org>
Message-ID: <1580379235.33.0.906343370847.issue39500@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Since the behavior was changed, I think we need a versionchanged directive.

This function was added in 3.0. Prior to 3.3 it was always successful (if you pass an unicode object, that is required for most of PyUnicode API). Py_FatalError was added in 3.3, because not all unicode object are now valid. But I am not sure that it could be triggered in real code without using some broken extensions.

It may be safer to return 0 instead of returning -1 or crashing if PyUnicode_READY() fails. If return -1 and set an exception, it can lead to an unexpected behavior if the calling code expects only 0/1, and maybe even to crash in debug build due to set an exception and returning value.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39500>
_______________________________________

From report at bugs.python.org  Thu Jan 30 05:26:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Jan 2020 10:26:29 +0000
Subject: [issue39424] [easy] test_signal: test_pidfd_send_signal() uses
 deprecated assertRaisesRegexp() method
In-Reply-To: <1579712181.32.0.0974422649306.issue39424@roundup.psfhosted.org>
Message-ID: <1580379989.35.0.577619305457.issue39424@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 38c878b56cff997de8fb04a586c963039b69b414 by damani42 in branch 'master':
bpo-39424: Use assertRaisesRegex instead of assertRaisesRegexp. (GH-18277)
https://github.com/python/cpython/commit/38c878b56cff997de8fb04a586c963039b69b414


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39424>
_______________________________________

From report at bugs.python.org  Thu Jan 30 05:27:59 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Jan 2020 10:27:59 +0000
Subject: [issue39424] [easy] test_signal: test_pidfd_send_signal() uses
 deprecated assertRaisesRegexp() method
In-Reply-To: <1579712181.32.0.0974422649306.issue39424@roundup.psfhosted.org>
Message-ID: <1580380079.89.0.19827412415.issue39424@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39424>
_______________________________________

From report at bugs.python.org  Thu Jan 30 05:31:06 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Jan 2020 10:31:06 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580380266.26.0.808265869428.issue39479@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Great. For clarity, here's a Python function giving the behaviour I'd expect from a 2-arg lcm:

    from math import gcd

    def lcm(a, b):
        if a == 0:
            return 0
        return abs(a // gcd(a, b) * b)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Thu Jan 30 05:34:01 2020
From: report at bugs.python.org (Philipp Rehs)
Date: Thu, 30 Jan 2020 10:34:01 +0000
Subject: [issue30256] Adding a SyncManager Queue proxy to a SyncManager dict
 or Namespace proxy raises an exception
In-Reply-To: <1493812414.86.0.361870744934.issue30256@psf.upfronthosting.co.za>
Message-ID: <1580380441.52.0.406114502474.issue30256@roundup.psfhosted.org>


Philipp Rehs <phhere at gmail.com> added the comment:

Are there any reasons why it does not get merged?
This issue is open since more than two years and the fix is quiet small

----------
nosy: +Philipp Rehs
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30256>
_______________________________________

From report at bugs.python.org  Thu Jan 30 05:41:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Jan 2020 10:41:23 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580380883.97.0.329399847887.issue39479@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If a < b, what is better,

    a // gcd(a, b) * b

or

    b // gcd(a, b) * a

? Or there is no difference?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:02:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Jan 2020 11:02:25 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580382145.85.0.52050429076.issue39489@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I used COUNT_ALLOCS for curiosity. But I needed slightly different information, so in any case I patched the code.

AFAIK COUNT_ALLOCS is used in some large projects (maybe Fedora). It was already discussed somewhere on the tracker, but I have no a link.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39489>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:04:43 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Jan 2020 11:04:43 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580382283.83.0.0919574558447.issue39479@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'd guess a // gcd(a, b) * b would be faster, on the basis that division is slower than multiplication. But I doubt it's worth worrying about for this implementation, given that the gcd call is likely to be the bottleneck as a and b get large.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:05:05 2020
From: report at bugs.python.org (Anthony Wee)
Date: Thu, 30 Jan 2020 11:05:05 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580382305.62.0.3319461894.issue39401@roundup.psfhosted.org>


Anthony Wee <antxwee at gmail.com> added the comment:

> Thanks Anthony for the report! I included your name as the reporter, though I don't see it on any of the pages.

No problem! Thanks Steve, Eryk, and Victor for jumping on this!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:18:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 11:18:39 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580383119.06.0.0698832793066.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ec3c99c8a73650d7833189bd973ec492564aa479 by Victor Stinner in branch 'master':
bpo-38631: Avoid Py_FatalError() in unicodeobject.c (GH-18281)
https://github.com/python/cpython/commit/ec3c99c8a73650d7833189bd973ec492564aa479


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:20:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 11:20:54 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580383254.42.0.0821136019344.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 17c68b8107e348aeaaa05f7ac5072cacff916022 by Victor Stinner in branch 'master':
bpo-38631: Replace Py_FatalError() with assert() in ceval.c (GH-18279)
https://github.com/python/cpython/commit/17c68b8107e348aeaaa05f7ac5072cacff916022


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:35:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 11:35:23 +0000
Subject: [issue39465] Design a subinterpreter friendly alternative to
 _Py_IDENTIFIER
In-Reply-To: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>
Message-ID: <1580384123.04.0.474591840811.issue39465@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Once I discussed with Eric Snow during a core developer sprint: _Py_IDENTIFIER() should use an "interpreter local storage" for identifiers values. _Py_IDENTIFIER() would only be a "key" and _PyUnicode_FromId() would store the value somewhere in a hash table stored in PyInterpreterState. Something similar to the TSS API:

* PyThread_create_key()
* PyThread_delete_key_value()
* PyThread_set_key_value()
* PyThread_get_key_value()

But per interpreter, rather than being per thread.

The key can be simply the variable address in memory. It only has to be unique in the process.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:41:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 11:41:22 +0000
Subject: [issue39465] Design a subinterpreter friendly alternative to
 _Py_IDENTIFIER
In-Reply-To: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>
Message-ID: <1580384482.44.0.78457456313.issue39465@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Both https://github.com/python/cpython/pull/18066 (collections module) and https://github.com/python/cpython/pull/18032 (asyncio module) ran into the problem where porting them to multi-phase initialisation involves replacing their usage of the `_Py_IDENTIFIER` macro with some other mechanism.

What is the problem between _Py_IDENTIFIER and multi-phase initialisation modules?

If both are incompatible, we may need a different but similar API: values would be stored in a hash table per module object. The hash table can be stored in the module object directly, or it can be store in a second hash table (module => hash table).

If we want a unified API, maybe we can use module=NULL (or any other marker) for "global" identifiers (not specific to a module).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:51:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 11:51:47 +0000
Subject: [issue39500] Document PyUnicode_IsIdentifier() function
In-Reply-To: <1580376155.12.0.83956121235.issue39500@roundup.psfhosted.org>
Message-ID: <1580385107.46.0.40778776597.issue39500@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Since the behavior was changed, I think we need a versionchanged directive.

Done.


> But I am not sure that it could be triggered in real code without using some broken extensions.

_PyUnicode_Ready() can fail in two cases: the Py_UNICODE* string contains a character outside [U+0000; U+10ffff] character range, or a memory allocation failed. Both cases look very unlikely, knowning that _PyUnicode_Ready() is only called if PyUnicode_IsIdentifier() is called on a string using the Python legacy C API (Py_UNICODE*).


> It may be safer to return 0 instead of returning -1 or crashing if PyUnicode_READY() fails.

Functions which don't use PyObject* as return type have the tradition of returning -1. A few examples:

* PyUnicode_GetLength()
* PyUnicode_CopyCharacters()
* PyUnicode_ReadChar() (return "(Py_UCS4)-1" on error)
* PyLong_AsUnsignedLong() (return "(unsigned long)-1" on error)
* etc.

I don't see why PyUnicode_IsIdentifier() deserves to behave differently.


> If return -1 and set an exception, it can lead to an unexpected behavior if the calling code expects only 0/1, and maybe even to crash in debug build due to set an exception and returning value.

I updated my PR to document the behavior change in the "Changes in the C API" section of What's New in Python 3.9 documentation.

Previously, the code crashed Python (Py_FatalError). So I'm confident that this case never occurred ever in the wild. We got zero bug report about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39500>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:53:21 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 30 Jan 2020 11:53:21 +0000
Subject: [issue39465] Design a subinterpreter friendly alternative to
 _Py_IDENTIFIER
In-Reply-To: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>
Message-ID: <1580385201.02.0.695380062415.issue39465@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

> What is the problem between _Py_IDENTIFIER and multi-phase initialisation modules?

AFAIK there is no problem now, except possibly a race condition when initializing the identifiers.
It seems it's too easy to conflate porting to multi-phase initialization and getting rid of static state.


The problem will come with per-interpreter reference counting, or when the `str` class is no longer shared across all interpreters. For that, we'll need either per-interpreter identifiers, or solve the issue in another way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:54:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 11:54:57 +0000
Subject: [issue39465] Design a subinterpreter friendly alternative to
 _Py_IDENTIFIER
In-Reply-To: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>
Message-ID: <1580385297.37.0.888357413468.issue39465@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> AFAIK there is no problem now, except possibly a race condition when initializing the identifiers.

The GIL avoids any risk of race condition, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:57:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 11:57:56 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580385476.49.0.21876910855.issue39489@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I started a thread on the python-dev mailing list:
https://mail.python.org/archives/list/python-dev at python.org/thread/YEY2TZIWC6HGMM5Y3QKWKMEBT5Y5C324/

Serhiy:
> I used COUNT_ALLOCS for curiosity. But I needed slightly different information, so in any case I patched the code.

Did you use it recently? I understand that the unmodified feature didn't help for your use case. Was it to debug memory leaks?


Serhiy:
> AFAIK COUNT_ALLOCS is used in some large projects (maybe Fedora). It was already discussed somewhere on the tracker, but I have no a link.

Did you read previous comments, especially msg360985? It's no longer used in Fedora :-) Technically, it's still used in the python2 package, but it's gone from python3 package. But this issue is about Python 3.9, not Python 2 ;-)

FYI I'm now working in the Python Maintenance team at Red Hat which maintains python2 and python3 packages of Fedora.

By the way, Charalampos Stratakis is also in my team and he replied on python-dev:

"I've never used this feature and it was quite the hassle to maintain those patches downstream, so in my biased opinion, I would welcome the removal."

https://mail.python.org/archives/list/python-dev at python.org/message/4BI64IXNZMJGXNHOA34UJ35V74IGJNZF/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39489>
_______________________________________

From report at bugs.python.org  Thu Jan 30 06:59:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 11:59:24 +0000
Subject: [issue39424] [easy] test_signal: test_pidfd_send_signal() uses
 deprecated assertRaisesRegexp() method
In-Reply-To: <1579712181.32.0.0974422649306.issue39424@roundup.psfhosted.org>
Message-ID: <1580385564.45.0.165206743123.issue39424@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks damani42 for the fix!


Hakan: "I want to work on this as my first contribution"

I'm sorry for you, damani42 was faster than you to propose a PR! You can look for other "newcomer friendly" issues on the bug tracker by searching per keyword.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39424>
_______________________________________

From report at bugs.python.org  Thu Jan 30 07:04:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Jan 2020 12:04:52 +0000
Subject: [issue39500] Document PyUnicode_IsIdentifier() function
In-Reply-To: <1580376155.12.0.83956121235.issue39500@roundup.psfhosted.org>
Message-ID: <1580385892.89.0.367003869761.issue39500@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Other examples are:

* PyObject_HasAttr
* PyObject_HasAttrString
* PyMapping_HasKey
* PyMapping_HasKeyString

They are bad examples, but can't be changed for backward compatibility. I wonder whether PyUnicode_IsIdentifier should also kept unchanged for backward compatibility.

There is also a number of *_Check functions which always succeeds.

Other example is _PyUnicode_EqualToASCIIString where the behavior is intentional.

PyUnicode_IsIdentifier() was not documented before. It makes easier to change its behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39500>
_______________________________________

From report at bugs.python.org  Thu Jan 30 07:07:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 12:07:45 +0000
Subject: [issue39500] Document PyUnicode_IsIdentifier() function
In-Reply-To: <1580376155.12.0.83956121235.issue39500@roundup.psfhosted.org>
Message-ID: <1580386065.99.0.358703690843.issue39500@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> They are bad examples, but can't be changed for backward compatibility.

I don't think that we should follow these bad examples :-) IMO ignoring silently bugs is a bad programming practice.

I don't expect PyUnicode_IsIdentifier() to be used outside Python. If it's used, I don't see why it would be a "non-ready string" in practice. The risk of regression is very close to zero. If it happens, it's no longer our fault, since I documented the behavior change ;-) Again, right now, Python does crash if this corner case occurs...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39500>
_______________________________________

From report at bugs.python.org  Thu Jan 30 07:09:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 12:09:18 +0000
Subject: [issue38631] Replace Py_FatalError() with regular Python exceptions
In-Reply-To: <1572352735.51.0.915792481752.issue38631@roundup.psfhosted.org>
Message-ID: <1580386158.86.0.46901940615.issue38631@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 2a4903fcce54c25807d362dbbbcfb32d0b494f9f by Victor Stinner in branch 'master':
bpo-38631: Add _Py_NO_RETURN to functions calling Py_FatalError() (GH-18278)
https://github.com/python/cpython/commit/2a4903fcce54c25807d362dbbbcfb32d0b494f9f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38631>
_______________________________________

From report at bugs.python.org  Thu Jan 30 07:14:21 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Jan 2020 12:14:21 +0000
Subject: [issue39489] Remove COUNT_ALLOCS special build
In-Reply-To: <1580321776.5.0.0072987667606.issue39489@roundup.psfhosted.org>
Message-ID: <1580386461.45.0.692779088568.issue39489@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It was many years ago, and I used it to get some statistics about using Python objects of some types. But it did not work as I wanted for cached integers etc. In any case I can patch Python again if I need such information.

Seems Fedora was the main user of this feature. If it is no longer used in Fedora, I think it can be safely removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39489>
_______________________________________

From report at bugs.python.org  Thu Jan 30 07:15:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 12:15:34 +0000
Subject: [issue38350] ./configure --with-pydebug should use -O0 rather than -Og
In-Reply-To: <1570034107.68.0.232468214894.issue38350@roundup.psfhosted.org>
Message-ID: <1580386534.92.0.115235248437.issue38350@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

There consensus seems to be towards the status quo: -Og is a good trade off between debug and performance for most core developers usage.

For the Fedora package, it may make sense to use -O0, but that should be discussed in Fedora ;-)

So I close the issue. Thanks for the interesting discussion :-)

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38350>
_______________________________________

From report at bugs.python.org  Thu Jan 30 07:18:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 12:18:13 +0000
Subject: [issue38063] Modify test_socket.py to use unittest test discovery
In-Reply-To: <1568025092.75.0.792665697576.issue38063@roundup.psfhosted.org>
Message-ID: <1580386693.16.0.0124504248291.issue38063@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

My PR 15751 didn't work. If someone else wants to give a try to fix this issue, please go ahead!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38063>
_______________________________________

From report at bugs.python.org  Thu Jan 30 07:48:53 2020
From: report at bugs.python.org (Thomas Perret)
Date: Thu, 30 Jan 2020 12:48:53 +0000
Subject: [issue39501] gettext's default localedir does not match documentation
Message-ID: <1580388533.66.0.705426741296.issue39501@roundup.psfhosted.org>


New submission from Thomas Perret <thomas.perret+python at gresille.org>:

gettext's documentation (Doc/library/gettext.rst:724) states that default locale directory is: "sys.prefix/share/locale" but the code in gettext module (Lib/gettext.py:63) uses "sys.base_prefix/share/locale"

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 361054
nosy: docs at python, moht
priority: normal
severity: normal
status: open
title: gettext's default localedir does not match documentation
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39501>
_______________________________________

From report at bugs.python.org  Thu Jan 30 08:23:44 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Jan 2020 13:23:44 +0000
Subject: [issue39434] Remove unnecessary logic of float __floordiv__
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1580390624.75.0.0396446784008.issue39434@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:


New changeset 8d49f7ceb4f961770ae61fe6a4033c4e61cc3288 by Dong-hee Na in branch 'master':
bpo-39434: Improve float __floordiv__ performance and error message (GH-18147)
https://github.com/python/cpython/commit/8d49f7ceb4f961770ae61fe6a4033c4e61cc3288


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 30 08:24:28 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Jan 2020 13:24:28 +0000
Subject: [issue39434] Remove unnecessary logic of float __floordiv__
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1580390668.93.0.813936932073.issue39434@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thank you!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 30 08:49:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 13:49:21 +0000
Subject: [issue39434] Remove unnecessary logic of float __floordiv__
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1580392161.21.0.199766544826.issue39434@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks, that's a nice optimization!

I'm surprised that creating a tuple of 2 items, get one item  directly into the C structure, and destroy the tuple is so slow (360 ns => 185 ns: 175 ns less). With my FASTCALL optimization on function calls, I recall that avoiding the creation a tuple of N items made function calls around 20 ns faster. Not 175 ns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 30 08:51:37 2020
From: report at bugs.python.org (EGuesnet)
Date: Thu, 30 Jan 2020 13:51:37 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
Message-ID: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>


New submission from EGuesnet <etienne.guesnet.external at atos.net>:

Hi,
I have an error during regression tests with Python3.8.1 on AIX 6.1 compiled with GCC 8.3.
It occurs only on 64 bit. Test passes on 32 bit.

```
======================================================================
ERROR: test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/opt/freeware/src/packages/BUILD/Python-3.8.1/64bit/Lib/test/test_zipfile.py", line 606, in test_add_file_after_2107
    self.assertRaises(struct.error, zipfp.write, TESTFN)
  File "/opt/freeware/src/packages/BUILD/Python-3.8.1/64bit/Lib/unittest/case.py", line 816, in assertRaises
    return context.handle('assertRaises', args, kwargs)
  File "/opt/freeware/src/packages/BUILD/Python-3.8.1/64bit/Lib/unittest/case.py", line 202, in handle
    callable_obj(*args, **kwargs)
  File "/opt/freeware/src/packages/BUILD/Python-3.8.1/64bit/Lib/zipfile.py", line 1739, in write
    zinfo = ZipInfo.from_file(filename, arcname,
  File "/opt/freeware/src/packages/BUILD/Python-3.8.1/64bit/Lib/zipfile.py", line 523, in from_file
    mtime = time.localtime(st.st_mtime)
OverflowError: localtime argument out of range
```

The PR associated to the new behavior is: https://github.com/python/cpython/pull/12726 (new on Python 3.8). Code is AIX specific. Is the code 32 bit only, or maybe the test was not updated?

-----

I can reproduce the behavior as follow:

```
$ python3.8_32
Python 3.8.1 (default, Jan 27 2020, 11:34:59) 
[GCC 8.3.0] on aix
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.localtime(4325562452)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: timestamp out of range for platform time_t

$ python3.8_64
Python 3.8.1 (default, Jan 27 2020, 11:30:15) 
[GCC 8.3.0] on aix
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.localtime(4325562452)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: localtime argument out of range

$ python3.7_32
Python 3.7.4 (default, Jan 15 2020, 15:50:53) 
[GCC 8.3.0] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.localtime(4325562452)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: timestamp out of range for platform time_t

$ python3.7_64
Python 3.7.4 (default, Jan 15 2020, 15:46:22) 
[GCC 8.3.0] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.localtime(4325562452)
time.struct_time(tm_year=2107, tm_mon=1, tm_mday=27, tm_hour=10, tm_min=7, tm_sec=32, tm_wday=3, tm_yday=27, tm_isdst=0)
```

----------
components: Tests
messages: 361058
nosy: EGuesnet
priority: normal
severity: normal
status: open
title: test_zipfile fails on AIX due to time.localtime
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 08:52:58 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 30 Jan 2020 13:52:58 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580392378.5.0.348076451618.issue39502@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 08:55:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 13:55:19 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580392519.97.0.690358482125.issue39502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I suggest to skip the test if time.localtime() fails with OverflowError.

Can you please try attached patch on AIX, on the master branch if possible? (Or on Python 3.8 at least.)

----------
keywords: +patch
nosy: +vstinner
Added file: https://bugs.python.org/file48872/test_zipfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 09:00:57 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 30 Jan 2020 14:00:57 +0000
Subject: [issue39434] Remove unnecessary logic of float __floordiv__
In-Reply-To: <1579789899.85.0.741189319798.issue39434@roundup.psfhosted.org>
Message-ID: <1580392857.31.0.147936762685.issue39434@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Victor: I suspect there's some compiler magic going on, too; a good compiler should be able to figure out that half of the div/mod calculation is not being used, and strip it out. That wouldn't have been possible before with the tuple packing and unpacking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39434>
_______________________________________

From report at bugs.python.org  Thu Jan 30 09:03:16 2020
From: report at bugs.python.org (EGuesnet)
Date: Thu, 30 Jan 2020 14:03:16 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580392996.63.0.0114674706013.issue39502@roundup.psfhosted.org>


EGuesnet <etienne.guesnet.external at atos.net> added the comment:

Tested on Python 3.8.1 on both 32 and 64 bits.
Test is now skipped.


test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile) ... skipped 'time.localtime(4386268800) raises OverflowError'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 09:05:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 14:05:48 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580393148.3.0.240237266471.issue39502@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17657
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18282

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 09:08:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 14:08:17 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580393297.28.0.588274724815.issue39502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Tested on Python 3.8.1 on both 32 and 64 bits. Test is now skipped.

Good. I created PR 18282 from my patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 09:20:03 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 30 Jan 2020 14:20:03 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580394003.84.0.34598577167.issue39502@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Probably this broke the 64-bit usage.

diff --git a/Python/pytime.c b/Python/pytime.c
index 54ddfc952b..6f13e62490 100644
--- a/Python/pytime.c
+++ b/Python/pytime.c
@@ -1059,7 +1059,7 @@ _PyTime_localtime(time_t t, struct tm *tm)
     return 0;
 #else /* !MS_WINDOWS */

-#ifdef _AIX
+#ifdef defined(_AIX) and (SIZEOF_LONG ==4)
     /* bpo-34373: AIX does not return NULL if t is too small or too large */
     if (t < -2145916800 /* 1902-01-01 */
        || t > 2145916800 /* 2038-01-01 */) {


Testing...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 09:36:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 14:36:51 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580395011.41.0.0277277438532.issue39502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Probably this broke the 64-bit usage.

I'm not sure of the meaning of your patch. Are you saying that localtime() supports timestamp after the year 2038 on 64-bit AIX? Did you test that time.localtime(2**32) actually works as expected?

In my timezone, Linux, I get:

$ python3
Python 3.7.6 (default, Dec 19 2019, 22:52:49) 
>>> import time; time.localtime(2**32)
time.struct_time(tm_year=2106, tm_mon=2, tm_mday=7, tm_hour=7, tm_min=28, tm_sec=16, tm_wday=6, tm_yday=38, tm_isdst=0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 09:40:46 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 30 Jan 2020 14:40:46 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580395246.73.0.268338444563.issue39502@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

>From memory I recall the 64-bit version worked with values above the threshold value that broke the 32-bit library.

And the additional test was needed because the AIX library (iirc did not return NULL on error) - so had to test range before the call to get an overflow.

Working up a test of 32 and 64-bit enviornments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 09:47:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 14:47:57 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580395677.25.0.116794826639.issue39502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset c232c9110cfefa0935cbf158e35e91746a8a9361 by Victor Stinner in branch 'master':
bpo-39502: Skip test_zipfile.test_add_file_after_2107() on AIX (GH-18282)
https://github.com/python/cpython/commit/c232c9110cfefa0935cbf158e35e91746a8a9361


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 09:48:16 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Jan 2020 14:48:16 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580395696.45.0.514341593246.issue39502@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17658
pull_request: https://github.com/python/cpython/pull/18283

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 09:52:32 2020
From: report at bugs.python.org (EGuesnet)
Date: Thu, 30 Jan 2020 14:52:32 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580395952.57.0.931992594087.issue39502@roundup.psfhosted.org>


EGuesnet <etienne.guesnet.external at atos.net> added the comment:

> I'm not sure of the meaning of your patch. Are you saying that localtime() supports timestamp after the year 2038 on 64-bit AIX? Did you test that time.localtime(2**32) actually works as expected?

I think it worked as expected before 3.8 on 64 bit.

On AIX 64bit, with Python3.7.4,

$ python3_64
Python 3.7.4 (default, Jan 15 2020, 15:46:22)
[GCC 8.3.0] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> import time; time.localtime(2**32)
time.struct_time(tm_year=2106, tm_mon=2, tm_mday=7, tm_hour=7, tm_min=28, tm_sec=16, tm_wday=6, tm_yday=38, tm_isdst=0)

and on 32bit

$ python3_32 
Python 3.7.4 (default, Jan 15 2020, 15:50:53) 
[GCC 8.3.0] on aix6
Type "help", "copyright", "credits" or "license" for more information.
>>> import time; time.localtime(2**32)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: timestamp out of range for platform time_t

With the new Python 3.8.1, on both 32 and 64bits,

Python 3.8.1 (default, Jan 30 2020, 11:23:14) 
[GCC 8.3.0] on aix
Type "help", "copyright", "credits" or "license" for more information.
>>> import time; time.localtime(2**32)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: localtime argument out of range

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 09:57:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 14:57:39 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580396259.76.0.318557016984.issue39502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-39502: Skip test_zipfile.test_add_file_after_2107() on AIX (GH-18282)

Even if localtime() is updated to support larger timestamp, this change is still needed for 32-bit AIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 10:05:14 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 30 Jan 2020 15:05:14 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580396714.52.0.843018054306.issue39502@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b841633cc2d7619cf4a7db108d91b14926450a6e by Miss Islington (bot) in branch '3.8':
bpo-39502: Skip test_zipfile.test_add_file_after_2107() on AIX (GH-18282)
https://github.com/python/cpython/commit/b841633cc2d7619cf4a7db108d91b14926450a6e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 10:06:29 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 30 Jan 2020 15:06:29 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580396789.45.0.685358065402.issue39502@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Seems to be working on 64-bit, starting 32-bit test (with overflow expected). Once finished will post a PR.

root at x065:[/data/prj/python/python3-3.9]./python
Python 3.9.0a3+ (heads/bpo-39502-dirty:8d49f7ceb4, Jan 30 2020, 14:47:52) [C] on aix
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.localtime(4325562452)
time.struct_time(tm_year=2107, tm_mon=1, tm_mday=27, tm_hour=9, tm_min=7, tm_sec=32, tm_wday=3, tm_yday=27, tm_isdst=0)
>>> time.gmtime(4325562452)
time.struct_time(tm_year=2107, tm_mon=1, tm_mday=27, tm_hour=9, tm_min=7, tm_sec=32, tm_wday=3, tm_yday=27, tm_isdst=0)
>>>

----------
components: +Interpreter Core
versions: +Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 10:08:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 15:08:53 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580396933.31.0.672156446589.issue39502@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Seems to be working on 64-bit, starting 32-bit test (with overflow expected). Once finished will post a PR.

test_time already has tests for timestamps after year 2038, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 10:11:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 15:11:29 +0000
Subject: [issue39503] [security] Denial of service in
 urllib.request.AbstractBasicAuthHandler
Message-ID: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Copy of an email received on the Python Security Response team, 9 days ago. I consider that it's not worth it to have an embargo on this vulnerability, so I make it public.

Hi there,

I believe I've found a denial-of-service (DoS) bug in
urllib.request.AbstractBasicAuthHandler. To start, I'm operating on some
background information from this document: HTTP authentication
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication>. The bug
itself is a ReDoS <https://www.regular-expressions.info/redos.html> bug
causing catastrophic backtracking. To reproduce the issue we can use the
following code:

from urllib.request import AbstractBasicAuthHandler
auth_handler = AbstractBasicAuthHandler()
auth_handler.http_error_auth_reqed(
    'www-authenticate',
    'unused',
    'unused',
    {
        'www-authenticate': 'Basic ' + ',' * 64 + ' ' + 'foo' + ' ' +
'realm'
    }
)

The issue itself is in the following regular expression:

rx = re.compile('(?:.*,)*[ \t]*([^ \t]+)[ \t]+'
                'realm=(["\']?)([^"\']*)\\2', re.I)

In particular, the (?:.*,)* portion. Since "." and "," overlap and there
are nested quantifiers we can cause catastrophic backtracking by repeating
a comma. Note that since AbstractBasicAuthHandler is vulnerable, then both
HTTPBasicAuthHandler and ProxyBasicAuthHandler are as well because they
call http_error_auth_reqed. Building from the HTTP authentication document
above, this means a server can send a specially crafted header along with
an HTTP 401 or HTTP 407 and cause a DoS on the client.

I won't speculate on the severity of the issue too much - you will surely
understand the impact better than I will. Although, the fact that this is
client-side as opposed to server-side appears to reduce the severity,
however the fact that it's a security-sensitive context (HTTP
authentication) may raise the severity.

One possible fix would be changing the rx expression to the following:

rx = re.compile('(?:[^,]*,)*[ \t]*([^ \t]+)[ \t]+'
                'realm=(["\']?)([^"\']*)\\2', re.I)

This removes the character overlap in the nested quantifier and thus
negates the catastrophic backtracking.

Let me know if you have any questions or what the next steps are from here.
Thanks for supporting Python security!

-- 
Matt Schwager

----------
components: Library (Lib)
messages: 361072
nosy: vstinner
priority: normal
severity: normal
status: open
title: [security] Denial of service in urllib.request.AbstractBasicAuthHandler
type: security
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39503>
_______________________________________

From report at bugs.python.org  Thu Jan 30 10:20:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 15:20:34 +0000
Subject: [issue39503] [security] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1580397634.1.0.548408349729.issue39503@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17659
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18284

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39503>
_______________________________________

From report at bugs.python.org  Thu Jan 30 10:26:41 2020
From: report at bugs.python.org (Michael Felt)
Date: Thu, 30 Jan 2020 15:26:41 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580398001.95.0.862844277667.issue39502@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
pull_requests: +17660
pull_request: https://github.com/python/cpython/pull/18285

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Thu Jan 30 10:30:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 15:30:40 +0000
Subject: [issue39503] [security] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1580398240.02.0.544230595468.issue39503@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I added this vulnerability to the following page to track fixes in all Python supported branches:
https://python-security.readthedocs.io/vuln/urllib-basic-auth-regex.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39503>
_______________________________________

From report at bugs.python.org  Thu Jan 30 10:49:50 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Thu, 30 Jan 2020 15:49:50 +0000
Subject: [issue39153] Clarify refcounting semantics of PyDict_SetItem[String]
In-Reply-To: <1577626439.88.0.846596028568.issue39153@roundup.psfhosted.org>
Message-ID: <1580399390.48.0.965908379712.issue39153@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

@nanjekyejoannah 
Thanks for the update :)

----------
nosy: +corona10
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39153>
_______________________________________

From report at bugs.python.org  Thu Jan 30 12:04:16 2020
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 30 Jan 2020 17:04:16 +0000
Subject: [issue36051] Drop the GIL during large bytes.join operations?
In-Reply-To: <1550667654.79.0.460473844528.issue36051@roundup.psfhosted.org>
Message-ID: <1580403856.59.0.317970397934.issue36051@roundup.psfhosted.org>


Skip Montanaro <skip.montanaro at gmail.com> added the comment:

I think to avoid compiler warnings about 'save' perhaps being used uninitialized, it should be initialized to NULL when declared on line 21 of Objects/stringlib/join.h.

----------
nosy: +skip.montanaro
status: closed -> open
Added file: https://bugs.python.org/file48873/join.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36051>
_______________________________________

From report at bugs.python.org  Thu Jan 30 12:26:52 2020
From: report at bugs.python.org (Kent Watsen)
Date: Thu, 30 Jan 2020 17:26:52 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1580405212.82.0.894085634754.issue18233@roundup.psfhosted.org>


Kent Watsen <kent+python at watsen.net> added the comment:

I don't understand the concern issues being raised for this patch, and also may have a use-case not mentioned yet.

For the concern issue, as I understand it, the ability to call getpeercert() or the proposed getpeercertchain() is only after the TLS session has been established.  As such, the SSL socket already established that there exists a valid chain of trust.  Thus these methods are primarily to provide visibility into what the peer passed *after* it had been authenticated, right?

That said, the reason I want to access the entire certificate chain passed by the client (i.e., client cert auth) is in order to validate that the client's cert (which may include some intermediates) authenticates to a specific trust anchor, rather than the bag of trust anchors loaded into the SSLContext (via load_verify_locations()) in order to authenticate a multiplicity of clients, each potentially leading to a different trust anchor.  

Not having getpeercertchain() means that all no client cert may contain a chain, i.e., the clients only ever transmit the end-entity cert itself.  This is unfortunate because the underlying SSL socket actually allows clients to send chains, it's just the lack being able to access the peercertchain in my code that seems to limit the solution.

----------
nosy: +kwatsen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Thu Jan 30 14:44:45 2020
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCa0LDQt9Cw0L3RhtC10LI=?=)
Date: Thu, 30 Jan 2020 19:44:45 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1580413485.73.0.0755204987603.issue39483@roundup.psfhosted.org>


?????? ???????? <heckad at yandex.ru> added the comment:

@asvetlov, I provided an example where else this useful feature would be. What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39483>
_______________________________________

From report at bugs.python.org  Thu Jan 30 16:20:06 2020
From: report at bugs.python.org (Martin Panter)
Date: Thu, 30 Jan 2020 21:20:06 +0000
Subject: [issue39353] Deprecate the binhex module,
 binhex4 and hexbin4 standards
In-Reply-To: <1579166085.65.0.30693146669.issue39353@roundup.psfhosted.org>
Message-ID: <1580419206.88.0.587270913457.issue39353@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Thanks Victor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39353>
_______________________________________

From report at bugs.python.org  Thu Jan 30 16:54:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 30 Jan 2020 21:54:31 +0000
Subject: [issue39500] Document PyUnicode_IsIdentifier() function
In-Reply-To: <1580376155.12.0.83956121235.issue39500@roundup.psfhosted.org>
Message-ID: <1580421271.32.0.793083425637.issue39500@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is not convenient to check the result for error. After we remove support of old PyUnicode API, PyUnicode_IsIdentifier() will be always succeeded.

Note that PyUnicode_IsIdentifier() still can crash if you pass a non-PyUnicode object or NULL. It is a prerequisite of this function that the argument must be a PyUnicode object. Add just yet one condition: it must be a ready PyUnicode object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39500>
_______________________________________

From report at bugs.python.org  Thu Jan 30 17:15:54 2020
From: report at bugs.python.org (Tim Peters)
Date: Thu, 30 Jan 2020 22:15:54 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580422554.76.0.947945511454.issue39479@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

And I in turn agree with everything Mark said ;-)  But I'll add that while the analogy to comb/perm is a good one, I think the case for lcm is stronger than for perm.  Not only is lcm more common in real life (although, no, not at all common overall!), perm was added at the same time as prod, and perm is essentially a special case of prod.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Thu Jan 30 17:33:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 30 Jan 2020 22:33:12 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1580423592.2.0.367895627614.issue39503@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

CVE-2020-8492 has been assigned to this vulnerability:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-8492

----------
title: [security] Denial of service in urllib.request.AbstractBasicAuthHandler -> [security][CVE-2020-8492] Denial of service in urllib.request.AbstractBasicAuthHandler

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39503>
_______________________________________

From report at bugs.python.org  Thu Jan 30 18:20:55 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 30 Jan 2020 23:20:55 +0000
Subject: [issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code
In-Reply-To: <1580309528.55.0.307294388242.issue39487@roundup.psfhosted.org>
Message-ID: <1580426455.32.0.525212877984.issue39487@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset 46874c26ee1fc752e2e6930efa1d223b2351edb8 by Hai Shi in branch 'master':
bpo-39487: Merge duplicated _Py_IDENTIFIER identifiers in C code (GH-18254)
https://github.com/python/cpython/commit/46874c26ee1fc752e2e6930efa1d223b2351edb8


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39487>
_______________________________________

From report at bugs.python.org  Thu Jan 30 18:21:51 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 30 Jan 2020 23:21:51 +0000
Subject: [issue39487] Merge duplicated _Py_IDENTIFIER identifiers in C code
In-Reply-To: <1580309528.55.0.307294388242.issue39487@roundup.psfhosted.org>
Message-ID: <1580426511.59.0.0139606454111.issue39487@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I just merged Hai Shi's PR, so I'm going to close assuming that took care of all the instances.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39487>
_______________________________________

From report at bugs.python.org  Thu Jan 30 19:05:59 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jan 2020 00:05:59 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580429159.08.0.19273008095.issue39479@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Perhaps add, is_prime() as well.  Conceptually, it is in the same family of functions.  Unlike lcm(), it is one that I would use and would improve Python's value as a teaching tool.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Thu Jan 30 19:37:08 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 31 Jan 2020 00:37:08 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1580431028.13.0.0140337911979.issue18233@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

> For the concern issue, as I understand it, the ability to call getpeercert() or the proposed getpeercertchain() is only after the TLS session has been established.  As such, the SSL socket already established that there exists a valid chain of trust.  Thus these methods are primarily to provide visibility into what the peer passed *after* it had been authenticated, right?

The issue is that "the cert chain provided by the client" and "the cert chain that was validated as trustworthy" might be different. For example, say you have trust roots A and B, and I have a leaf certificate with a valid signature by B. If I pass the chain [A, leaf cert], then openssl's trust validation code might look at that and say "yep, this leaf cert is signed by root B, I trust root B, cool, the connection is good. Also there's a random A cert here, but whatever, that doesn't change anything".

In this case, for your use case, you want to get back the chain [B, leaf cert], because that's the chain that was actually validated. If you instead got the chain the client gave you, then you might be fooled into thinking that this cert chained to root A, when it actually didn't, and make the wrong trust decision.

That's why we need to be careful to distinguish between these two possible chains.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Thu Jan 30 19:51:59 2020
From: report at bugs.python.org (Tim Peters)
Date: Fri, 31 Jan 2020 00:51:59 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580431919.89.0.565439675962.issue39479@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Raymond, there was a thread a while back about adding an `imath` module, to package the number-theoretic functions that frequently come up.  _All_ these things should really go into that instead, IMO.  `math` started as a thin wrapper around C's libm, and has been losing its once-exclusive focus on functions for working with Python floats.  I think that focus was valuable.

In that older thread, I suggested a `probable_prime(n)` predicate function, and posted my pure-Python Miller-Rabin implementation.  Simple (as such things go), but I wouldn't aim to compete with (say) gmp.

I don't think `is_prime(n)` is suitable for Python.  Proving that a large integer absolutely is prime is either quite slow or quite complicated.  In practice, even professionals in critical applications are happy to settle for probabilistic assurances, because an arbitrarily tiny probability of error can be obtained very much faster than a deterministic proof.

Anyway ;-) , ya, I like the idea, but I'd sure like it to go into a module where it obviously belongs.  Also a function, e.g., to generate primes, and ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Thu Jan 30 20:55:49 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jan 2020 01:55:49 +0000
Subject: [issue38792] IDLE calltips may not properly close on KeyboardInterrupt
In-Reply-To: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>
Message-ID: <1580435749.88.0.117401630102.issue38792@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset bfdeaa37b3df7466624c17f9450d2bd1c3d95edf by Zackery Spytz in branch 'master':
bpo-38792: Remove IDLE shell calltip before new prompt. (#17150)
https://github.com/python/cpython/commit/bfdeaa37b3df7466624c17f9450d2bd1c3d95edf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38792>
_______________________________________

From report at bugs.python.org  Thu Jan 30 20:55:56 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Jan 2020 01:55:56 +0000
Subject: [issue38792] IDLE calltips may not properly close on KeyboardInterrupt
In-Reply-To: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>
Message-ID: <1580435756.08.0.288393528474.issue38792@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17661
pull_request: https://github.com/python/cpython/pull/18287

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38792>
_______________________________________

From report at bugs.python.org  Thu Jan 30 20:56:03 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Jan 2020 01:56:03 +0000
Subject: [issue38792] IDLE calltips may not properly close on KeyboardInterrupt
In-Reply-To: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>
Message-ID: <1580435763.73.0.981660037721.issue38792@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +17662
pull_request: https://github.com/python/cpython/pull/18288

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38792>
_______________________________________

From report at bugs.python.org  Thu Jan 30 21:12:27 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 31 Jan 2020 02:12:27 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580436747.73.0.232213101835.issue39401@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 51332c467ed2e07a191f903d554d0c54248e4d88 by Steve Dower in branch '3.6':
[3.6] bpo-39401: Avoid unsafe DLL load on Windows 7 and earlier (GH-18231) (GH-18233)
https://github.com/python/cpython/commit/51332c467ed2e07a191f903d554d0c54248e4d88


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Thu Jan 30 21:12:38 2020
From: report at bugs.python.org (Shantanu)
Date: Fri, 31 Jan 2020 02:12:38 +0000
Subject: [issue39504] inspect.signature throws RuntimeError on
 select.epoll.register
Message-ID: <1580436758.94.0.47641276989.issue39504@roundup.psfhosted.org>


New submission from Shantanu <hauntsaninja at gmail.com>:

>From the documentation of `inspect.signature` it seems we should never have a RuntimeError:
```
Raises ValueError if no signature can be provided, and TypeError if that type of object is not supported.
```

The easiest thing to do is just turn the RuntimeError into a ValueError... but I'll take a deeper look and see if I can actually fix this.

Traceback below:
```
>>> import sys
>>> sys.version
'3.8.0 (default, Nov 14 2019, 22:29:45) \n[GCC 5.4.0 20160609]'
>>> import inspect
>>> import select
>>> inspect.signature(select.epoll.register)
Traceback (most recent call last):
  File "/usr/lib/python3.8/inspect.py", line 2004, in wrap_value
    value = eval(s, module_dict)
  File "<string>", line 1, in <module>
NameError: name 'EPOLLIN' is not defined
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/usr/lib/python3.8/inspect.py", line 2007, in wrap_value
    value = eval(s, sys_module_dict)
  File "<string>", line 1, in <module>
NameError: name 'EPOLLIN' is not defined
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/inspect.py", line 3093, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "/usr/lib/python3.8/inspect.py", line 2842, in from_callable
    return _signature_from_callable(obj, sigcls=cls,
  File "/usr/lib/python3.8/inspect.py", line 2296, in _signature_from_callable
    return _signature_from_builtin(sigcls, obj,
  File "/usr/lib/python3.8/inspect.py", line 2109, in _signature_from_builtin
    return _signature_fromstr(cls, func, s, skip_bound_arg)
  File "/usr/lib/python3.8/inspect.py", line 2057, in _signature_fromstr
    p(name, default)
  File "/usr/lib/python3.8/inspect.py", line 2039, in p
    default_node = RewriteSymbolics().visit(default_node)
  File "/usr/lib/python3.8/ast.py", line 360, in visit
    return visitor(node)
  File "/usr/lib/python3.8/ast.py", line 445, in generic_visit
    new_node = self.visit(old_value)
  File "/usr/lib/python3.8/ast.py", line 360, in visit
    return visitor(node)
  File "/usr/lib/python3.8/ast.py", line 445, in generic_visit
    new_node = self.visit(old_value)
  File "/usr/lib/python3.8/ast.py", line 360, in visit
    return visitor(node)
  File "/usr/lib/python3.8/inspect.py", line 2031, in visit_Name
    return wrap_value(node.id)
  File "/usr/lib/python3.8/inspect.py", line 2009, in wrap_value
    raise RuntimeError()
RuntimeError
```

----------
components: Library (Lib)
messages: 361089
nosy: hauntsaninja
priority: normal
severity: normal
status: open
title: inspect.signature throws RuntimeError on select.epoll.register

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39504>
_______________________________________

From report at bugs.python.org  Thu Jan 30 21:12:49 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Jan 2020 02:12:49 +0000
Subject: [issue38792] IDLE calltips may not properly close on KeyboardInterrupt
In-Reply-To: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>
Message-ID: <1580436769.82.0.169075659268.issue38792@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8d021140866d050f90a4b44c2607f21be43208c1 by Miss Islington (bot) in branch '3.7':
bpo-38792: Remove IDLE shell calltip before new prompt. (GH-17150)
https://github.com/python/cpython/commit/8d021140866d050f90a4b44c2607f21be43208c1


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38792>
_______________________________________

From report at bugs.python.org  Thu Jan 30 21:14:13 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 31 Jan 2020 02:14:13 +0000
Subject: [issue39401] [CVE-2020-8315] Unsafe dll loading in getpathp.c on Win7
In-Reply-To: <1579568535.47.0.867871543099.issue39401@roundup.psfhosted.org>
Message-ID: <1580436853.83.0.644453295838.issue39401@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
priority: deferred blocker -> 
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39401>
_______________________________________

From report at bugs.python.org  Thu Jan 30 21:14:20 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Jan 2020 02:14:20 +0000
Subject: [issue38792] IDLE calltips may not properly close on KeyboardInterrupt
In-Reply-To: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>
Message-ID: <1580436860.74.0.975536191677.issue38792@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 83d3202b92fb4c2fc6df5b035d57f3a1cf715f20 by Miss Islington (bot) in branch '3.8':
bpo-38792: Remove IDLE shell calltip before new prompt. (GH-17150)
https://github.com/python/cpython/commit/83d3202b92fb4c2fc6df5b035d57f3a1cf715f20


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38792>
_______________________________________

From report at bugs.python.org  Thu Jan 30 21:16:03 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jan 2020 02:16:03 +0000
Subject: [issue38792] IDLE calltips may not properly close on KeyboardInterrupt
In-Reply-To: <1573714051.12.0.86899018089.issue38792@roundup.psfhosted.org>
Message-ID: <1580436963.92.0.883578587562.issue38792@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On the issue, Tal pointed out that SyntaxError leaves a calltip after a new >>> prompt.  Also fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38792>
_______________________________________

From report at bugs.python.org  Thu Jan 30 21:27:10 2020
From: report at bugs.python.org (Kent Watsen)
Date: Fri, 31 Jan 2020 02:27:10 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1580437630.46.0.927434965129.issue18233@roundup.psfhosted.org>


Kent Watsen <kent+python at watsen.net> added the comment:

It seems that we're talking about the same thing, but I want the cert-chain the peer sent without any smarts, exactly how OpenSSL's SSL_get_peer_cert_chain() works and, importantly, without stapling any root chain certs the client did not send itself (though it's okay if the client did, in which case those certs should be included).

I'm not following your "I pass the chain [A, leaf cert]" comment, if leaf-cert is signed by B, then this should obviously fail.  Maybe you meant to say that A and B are loaded into a bag and that validation test is [bag, leaf-cert]?

Regardless, I don't think Python should coddle developers.  Assuming the docs are accurate, competent developers with crypto-clue will be fine.  Many crypto library docs encourage tourists to stay away.   That said, if smarts are wanted, let's choose a name that doesn't overlap with the existing OpenSSL name...get_authed_cert_chain() ?

But, please, can a "peer_cert_chain()" wrapping the OpenSSL call be release ASAP, buying time to ponder the merits of smart calls for another day?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Fri Jan 31 03:24:20 2020
From: report at bugs.python.org (Fuzheng Duan)
Date: Fri, 31 Jan 2020 08:24:20 +0000
Subject: =?utf-8?b?W2lzc3VlMzk1MDVdIHJlZHVuZGFudCDigJgv4oCZIGluICRlbnY6VklSVFVB?=
 =?utf-8?q?L=5FENV_when_use_venv_in_powershell?=
Message-ID: <1580459060.25.0.800819724263.issue39505@roundup.psfhosted.org>


New submission from Fuzheng Duan <duanfuzheng at gmail.com>:

When windows users use "python -m venv ENV_DIR", a python virtual environment will be created in ENV_DIR. 
Powershell users use ENV_DIR\Scripts\Activate.ps1 to activate virtual environment.
In powershell, a environment variable, "$env:VIRTUAL_ENV", is set and used by many tools to determine that there is an activated venv. In bash, it is "$VIRTUAL_ENV"
In python3.8 and python3.9, $env:VIRTUAL_ENV has a redundant '/', for example:
PS C:\Users\Test> python -m venv test_venv
PS C:\Users\Test> .\test_venv\Scripts\Activate.ps1
PS C:\Users\Test> $env:VIRTUAL_ENV
C:\Users\Test\test_venv/

using python3.7, or using virtualenv with python3.8 or 3.9, or in linux, there will be no such a '/' in the end.

This '/' matters because some tools many tools use this environment variable, for example, oh-my-posh will take "test_venv/" as virtual environment name rather than "test_venv"(Although venv's activate.ps 1 itself's default prompt is correct). And from the perspective of semantics and consistency with other platform, the '/' is redundant.

----------
components: Library (Lib)
messages: 361094
nosy: Schwarzichet
priority: normal
severity: normal
status: open
title: redundant ?/? in $env:VIRTUAL_ENV when use venv in powershell
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39505>
_______________________________________

From report at bugs.python.org  Fri Jan 31 03:32:38 2020
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 31 Jan 2020 08:32:38 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1580459558.84.0.559961474081.issue18233@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

I'm not sure I agree about assuming that users will be able to work around these issues... I mean, nothing personal, I'm sure you're well-informed and maybe your code would work fine, but if you don't understand my example then how can you be entirely confident that you really understand all the risks that your code needs to watch out for?

Anyway, the proposed PR exposes both methods, so that's not a problem; it's just waiting on someone with openssl expertise like Christian to review it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Fri Jan 31 04:21:08 2020
From: report at bugs.python.org (Fuzheng Duan)
Date: Fri, 31 Jan 2020 09:21:08 +0000
Subject: =?utf-8?b?W2lzc3VlMzk1MDVdIHJlZHVuZGFudCDigJgv4oCZIGluICRlbnY6VklSVFVB?=
 =?utf-8?q?L=5FENV_when_use_venv_in_powershell?=
In-Reply-To: <1580459060.25.0.800819724263.issue39505@roundup.psfhosted.org>
Message-ID: <1580462468.04.0.80198070421.issue39505@roundup.psfhosted.org>


Change by Fuzheng Duan <duanfuzheng at gmail.com>:


----------
keywords: +patch
pull_requests: +17663
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18290

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39505>
_______________________________________

From report at bugs.python.org  Fri Jan 31 04:44:32 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 31 Jan 2020 09:44:32 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1580463872.74.0.971661065422.issue39483@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Explicit error is better than error-prone design.
Think that we will deprecate asyncio.get_event_loop() and the loop instantiation on-demand in the main thread.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39483>
_______________________________________

From report at bugs.python.org  Fri Jan 31 05:30:54 2020
From: report at bugs.python.org (Gabriele Tornetta)
Date: Fri, 31 Jan 2020 10:30:54 +0000
Subject: [issue39506] operator |= on sets does not behave like the update
 method
Message-ID: <1580466654.94.0.209518584933.issue39506@roundup.psfhosted.org>


New submission from Gabriele Tornetta <phoenix1987 at gmail.com>:

def outer():
  a=set()
  def inner():
    a |= set(["A"])
  inner()
  return a

print(outer())

Traceback (most recent call last):
  File "main.py", line 8, in <module>
    print(outer())
  File "main.py", line 5, in outer
    inner()
  File "main.py", line 4, in inner
    a |= set(["A"])
UnboundLocalError: local variable 'a' referenced before assignment

However, the update method works as expected:

def outer():
  a=set()
  def inner():
    a.update(set(["A"]))
  inner()
  return a

print(outer())

{'A'}

----------
components: Interpreter Core
messages: 361097
nosy: Gabriele Tornetta
priority: normal
severity: normal
status: open
title: operator |= on sets does not behave like the update method
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39506>
_______________________________________

From report at bugs.python.org  Fri Jan 31 05:44:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Jan 2020 10:44:19 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580467459.21.0.141270808836.issue39479@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I dislike the idea of adding a is_prime() function in Python since users will likely stress Python with huge numbers and then complain that Python is too slow. Correct is_prime() is very slow for large numbers, and statistically approach is not 100% correct... Or we may have to add both approaches. But then you have to pick an algorithm which would fit "most use cases".

I concur with Tim, it would be better to put such opinionated code on PyPI ;-)

--

I'm -0 on adding math.lcm(). For example, I failed to find any request to add such function on python-ideas archives. This issue seems to be the first user request.

I'm not opposed to add it. Some people seem to like the idea of the completeness of the stdlib (gcd & lcm go together). So if someone wants to add it, go ahead and propose a PR :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Fri Jan 31 05:46:09 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 31 Jan 2020 10:46:09 +0000
Subject: [issue39506] operator |= on sets does not behave like the update
 method
In-Reply-To: <1580466654.94.0.209518584933.issue39506@roundup.psfhosted.org>
Message-ID: <1580467569.23.0.556127862656.issue39506@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Take a look at https://docs.python.org/3/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value

What's happening is that because `a |= x` is treated as an assignment, i.e `a = a | x`. The compiler treats it as a local variable, but since it hasn't been initialized in inner() before it reaches `a |= set(["A"])` it fails with UnboundLocalError.

----------
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39506>
_______________________________________

From report at bugs.python.org  Fri Jan 31 06:08:44 2020
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCa0LDQt9Cw0L3RhtC10LI=?=)
Date: Fri, 31 Jan 2020 11:08:44 +0000
Subject: [issue39483] Proposial add loop parametr to run in asyncio
In-Reply-To: <1580298747.78.0.00209746550488.issue39483@roundup.psfhosted.org>
Message-ID: <1580468924.86.0.299265848751.issue39483@roundup.psfhosted.org>


?????? ???????? <heckad at yandex.ru> added the comment:

Where can I find issue which you are discussing for this thread?

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39483>
_______________________________________

From report at bugs.python.org  Fri Jan 31 06:29:46 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 31 Jan 2020 11:29:46 +0000
Subject: =?utf-8?b?W2lzc3VlMzk1MDVdIHJlZHVuZGFudCDigJgv4oCZIGluICRlbnY6VklSVFVB?=
 =?utf-8?q?L=5FENV_when_use_venv_in_powershell?=
In-Reply-To: <1580459060.25.0.800819724263.issue39505@roundup.psfhosted.org>
Message-ID: <1580470186.8.0.953923207536.issue39505@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39505>
_______________________________________

From report at bugs.python.org  Fri Jan 31 06:32:39 2020
From: report at bugs.python.org (Natanael Copa)
Date: Fri, 31 Jan 2020 11:32:39 +0000
Subject: [issue21622] ctypes.util incorrectly fails for libraries without
 DT_SONAME
In-Reply-To: <1401593302.24.0.994822187168.issue21622@psf.upfronthosting.co.za>
Message-ID: <1580470359.26.0.753068864995.issue21622@roundup.psfhosted.org>


Change by Natanael Copa <ncopa at alpinelinux.org>:


----------
nosy: +ncopa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21622>
_______________________________________

From report at bugs.python.org  Fri Jan 31 07:15:37 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 31 Jan 2020 12:15:37 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580472937.77.0.880294060551.issue39479@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

is_prime that's always correct is probably not the right thing to go into math. Besides, now we have isqrt, it's just

    n>1 and n&1 and all(n%d for d in range(3,isqrt(n)+1,2))

-- yes, it's damn slow, but so is everything else you want to be absolutely correct. :-]

is_probable_prime is another matter, but there is an enormous amount of bikeshedding about the API of that one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Fri Jan 31 07:17:25 2020
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 31 Jan 2020 12:17:25 +0000
Subject: [issue39479] [RFE] Add math.lcm() function: Least Common Multiple
In-Reply-To: <1580219563.58.0.839733743791.issue39479@roundup.psfhosted.org>
Message-ID: <1580473044.99.0.857291637234.issue39479@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

And yeah, I managed to leave out 2. Speaking about "often implemented wrong"... :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39479>
_______________________________________

From report at bugs.python.org  Fri Jan 31 07:52:22 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Fri, 31 Jan 2020 12:52:22 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1580475142.21.0.179441510745.issue39350@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

I believe there is a regression here.

numpy fails to build with Python 3.9.0a3.

________________________ TestMatmul.test_matmul_object _________________________
self = <numpy.core.tests.test_multiarray.TestMatmul object at 0x7ff9bc008ca0>
    def test_matmul_object(self):
        import fractions
    
        f = np.vectorize(fractions.Fraction)
        def random_ints():
            return np.random.randint(1, 1000, size=(10, 3, 3))
>       M1 = f(random_ints(), random_ints())
f          = <numpy.vectorize object at 0x7ff9bc6751f0>
fractions  = <module 'fractions' from '/usr/lib64/python3.9/fractions.py'>
random_ints = <function TestMatmul.test_matmul_object.<locals>.random_ints at 0x7ff9bcc2d700>
self       = <numpy.core.tests.test_multiarray.TestMatmul object at 0x7ff9bc008ca0>
numpy/core/tests/test_multiarray.py:6259: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
numpy/lib/function_base.py:2091: in __call__
    return self._vectorize_call(func=func, args=vargs)
numpy/lib/function_base.py:2161: in _vectorize_call
    ufunc, otypes = self._get_ufunc_and_otypes(func=func, args=args)
numpy/lib/function_base.py:2121: in _get_ufunc_and_otypes
    outputs = func(*inputs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
cls = <class 'fractions.Fraction'>, numerator = 483, denominator = 809
    def __new__(cls, numerator=0, denominator=None, *, _normalize=True):
        """Constructs a Rational.
    
        Takes a string like '3/2' or '1.5', another Rational instance, a
        numerator/denominator pair, or a float.
    
        Examples
        --------
    
        >>> Fraction(10, -8)
        Fraction(-5, 4)
        >>> Fraction(Fraction(1, 7), 5)
        Fraction(1, 35)
        >>> Fraction(Fraction(1, 7), Fraction(2, 3))
        Fraction(3, 14)
        >>> Fraction('314')
        Fraction(314, 1)
        >>> Fraction('-35/4')
        Fraction(-35, 4)
        >>> Fraction('3.1415') # conversion from numeric string
        Fraction(6283, 2000)
        >>> Fraction('-47e-2') # string may include a decimal exponent
        Fraction(-47, 100)
        >>> Fraction(1.47)  # direct construction from float (exact conversion)
        Fraction(6620291452234629, 4503599627370496)
        >>> Fraction(2.25)
        Fraction(9, 4)
        >>> Fraction(Decimal('1.47'))
        Fraction(147, 100)
    
        """
        self = super(Fraction, cls).__new__(cls)
    
        if denominator is None:
            if type(numerator) is int:
                self._numerator = numerator
                self._denominator = 1
                return self
    
            elif isinstance(numerator, numbers.Rational):
                self._numerator = numerator.numerator
                self._denominator = numerator.denominator
                return self
    
            elif isinstance(numerator, (float, Decimal)):
                # Exact conversion
                self._numerator, self._denominator = numerator.as_integer_ratio()
                return self
    
            elif isinstance(numerator, str):
                # Handle construction from strings.
                m = _RATIONAL_FORMAT.match(numerator)
                if m is None:
                    raise ValueError('Invalid literal for Fraction: %r' %
                                     numerator)
                numerator = int(m.group('num') or '0')
                denom = m.group('denom')
                if denom:
                    denominator = int(denom)
                else:
                    denominator = 1
                    decimal = m.group('decimal')
                    if decimal:
                        scale = 10**len(decimal)
                        numerator = numerator * scale + int(decimal)
                        denominator *= scale
                    exp = m.group('exp')
                    if exp:
                        exp = int(exp)
                        if exp >= 0:
                            numerator *= 10**exp
                        else:
                            denominator *= 10**-exp
                if m.group('sign') == '-':
                    numerator = -numerator
    
            else:
                raise TypeError("argument should be a string "
                                "or a Rational instance")
    
        elif type(numerator) is int is type(denominator):
            pass # *very* normal case
    
        elif (isinstance(numerator, numbers.Rational) and
            isinstance(denominator, numbers.Rational)):
            numerator, denominator = (
                numerator.numerator * denominator.denominator,
                denominator.numerator * numerator.denominator
                )
        else:
            raise TypeError("both arguments should be "
                            "Rational instances")
    
        if denominator == 0:
            raise ZeroDivisionError('Fraction(%s, 0)' % numerator)
        if _normalize:
            if type(numerator) is int is type(denominator):
                # *very* normal case
                g = math.gcd(numerator, denominator)
                if denominator < 0:
                    g = -g
            else:
>               g = _gcd(numerator, denominator)
E               NameError: name '_gcd' is not defined
__class__  = <class 'fractions.Fraction'>
_normalize = True
cls        = <class 'fractions.Fraction'>
denominator = 809
numerator  = 483
self       = <[AttributeError("_numerator") raised in repr()] Fraction object at 0x7ff9bc6753a0>
/usr/lib64/python3.9/fractions.py:164: NameError


This removed _gcd, but it is still called in:

https://github.com/python/cpython/blob/58a4054760bffbb20aff90290dd0f3554f7bea42/Lib/fractions.py#L164

----------
nosy: +hroncok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39350>
_______________________________________

From report at bugs.python.org  Fri Jan 31 08:09:43 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Fri, 31 Jan 2020 13:09:43 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1580476183.38.0.226752285705.issue39350@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

Reproducer:

class myint(int):
    def __mul__(self, other):
        return type(self)(int(self)*int(other))
    @property
    def numerator(self):
        return type(self)(super().numerator)
    @property
    def denominator(self):
        return type(self)(super().denominator)


Before:

>>> fractions.Fraction(myint(1), myint(2))
Fraction(1, 2)


After:

>>> fractions.Fraction(myint(1), myint(2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.9/fractions.py", line 164, in __new__
    g = _gcd(numerator, denominator)
NameError: name '_gcd' is not defined

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39350>
_______________________________________

From report at bugs.python.org  Fri Jan 31 08:31:30 2020
From: report at bugs.python.org (Henry S. Thompson)
Date: Fri, 31 Jan 2020 13:31:30 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
 violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1580477490.76.0.480044032047.issue12731@roundup.psfhosted.org>


Henry S. Thompson <ht at inf.ed.ac.uk> added the comment:

[One year and 2 days later... :-[

Is this fixed in 3.9?  If not, the Versions list above should be updated.

The failure of lower() to preserve 'alpha-ness' is a serious bug, it causes significant failures in e.g. Turkish NLP, and it's _not_ just a failure of the documentation!

Please can we move this to category Unicode and get at least this aspect of the problem fixed?  Should I raise a separate issue on isalpha() etc.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12731>
_______________________________________

From report at bugs.python.org  Fri Jan 31 08:32:41 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Fri, 31 Jan 2020 13:32:41 +0000
Subject: [issue39507] http library missing HTTP status code 418 "I'm a teapot"
Message-ID: <1580477561.46.0.283786859287.issue39507@roundup.psfhosted.org>


New submission from Ross Rhodes <ross.rhodes at hotmail.co.uk>:

http library missing HTTP status code 418 "I'm a teapot".

----------
messages: 361106
nosy: trrhodes
priority: normal
severity: normal
status: open
title: http library missing HTTP status code 418 "I'm a teapot"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39507>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:05:49 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jan 2020 14:05:49 +0000
Subject: [issue12731] python lib re uses obsolete sense of \w in full
 violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1580479549.7.0.198917248278.issue12731@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee: docs at python -> 
components: +Unicode -Documentation
nosy: +benjamin.peterson, lemburg, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12731>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:14:36 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 31 Jan 2020 14:14:36 +0000
Subject: [issue39507] http library missing HTTP status code 418 "I'm a teapot"
In-Reply-To: <1580477561.46.0.283786859287.issue39507@roundup.psfhosted.org>
Message-ID: <1580480076.81.0.128749379544.issue39507@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

I add martin.panter to review this issue as the core developer.

----------
nosy: +corona10, martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39507>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:16:59 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Fri, 31 Jan 2020 14:16:59 +0000
Subject: [issue39507] http library missing HTTP status code 418 "I'm a teapot"
In-Reply-To: <1580477561.46.0.283786859287.issue39507@roundup.psfhosted.org>
Message-ID: <1580480219.15.0.182010233238.issue39507@roundup.psfhosted.org>


Change by Ross Rhodes <ross.rhodes at hotmail.co.uk>:


----------
keywords: +patch
pull_requests: +17665
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18291

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39507>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:19:55 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 31 Jan 2020 14:19:55 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1580480395.05.0.973682262011.issue39350@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39350>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:23:05 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 31 Jan 2020 14:23:05 +0000
Subject: [issue39507] http library missing HTTP status code 418 "I'm a teapot"
In-Reply-To: <1580477561.46.0.283786859287.issue39507@roundup.psfhosted.org>
Message-ID: <1580480585.16.0.97252363057.issue39507@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

IMHO, Although this status code is also listed on the MDN guide,
IANA left 418 as the unassigned code.

ref0: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
ref1: https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39507>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:32:32 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 31 Jan 2020 14:32:32 +0000
Subject: [issue37304] compiler need support in(de)crement operation or all of
 it should have syntax error.
In-Reply-To: <1560678383.11.0.0486916958299.issue37304@roundup.psfhosted.org>
Message-ID: <1580481152.8.0.996341645238.issue37304@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17666
pull_request: https://github.com/python/cpython/pull/18292

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37304>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:40:02 2020
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 31 Jan 2020 14:40:02 +0000
Subject: [issue39279] Don't allow non-Ascii digits in platform.py
In-Reply-To: <1578603731.26.0.701759063569.issue39279@roundup.psfhosted.org>
Message-ID: <1580481602.8.0.877987917016.issue39279@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

Hey Victor, adding you here. This ticket is a continuation of the thread on the Python security mailing list. I see that there isn't a consensus here for changing from \d to [0-9]. Can you make a decision on whether to go ahead with this issue or not? Otherwise we can close it, and the corresponding PR.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39279>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:42:08 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 31 Jan 2020 14:42:08 +0000
Subject: [issue37304] compiler need support in(de)crement operation or all of
 it should have syntax error.
In-Reply-To: <1560678383.11.0.0486916958299.issue37304@roundup.psfhosted.org>
Message-ID: <1580481728.53.0.604975070812.issue37304@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

A discussion was initiated in https://discuss.python.org/t/why-compiler-doesnt-support-in-de-crement-operation-should-we-support-it/2181.

And most of user tend not to support this in(de)crement operation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37304>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:44:47 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 31 Jan 2020 14:44:47 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1580481887.09.0.813730239032.issue39350@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The relevant piece of Python code from fractions.py looks like this:

    if type(numerator) is int is type(denominator):
        # *very* normal case
        g = math.gcd(numerator, denominator)
        if denominator < 0:
            g = -g
    else:
        g = _gcd(numerator, denominator)

I wonder whether we should simply drop the type check: math.gcd should accept anything that supports __index__ (and that includes NumPy integer types and anything that implements numbers.Integral).

OTOH, math.gcd will return a plain int, and if we have some subclass myint of int, we might want all the arithmetic to stay in the domain of myints (though I'm not really sure _why_ we'd want that). In that case we'll need to restore the pure Python _gcd implementation.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39350>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:48:02 2020
From: report at bugs.python.org (haim)
Date: Fri, 31 Jan 2020 14:48:02 +0000
Subject: [issue39508] no module curses error although i downloaded the module
 - windows 10
Message-ID: <1580482082.1.0.922196738704.issue39508@roundup.psfhosted.org>


New submission from haim <haim358123 at gmail.com>:

hi,
when i run my code its get error that ModuleNotFoundError: No module named '_curses'
altough i download windoows curses 2.1.0 library
i add a pictures
thanx

----------
files: p204.PNG
messages: 361112
nosy: haim986
priority: normal
severity: normal
status: open
title: no module curses error although i downloaded the module - windows 10
type: compile error
versions: Python 3.7
Added file: https://bugs.python.org/file48874/p204.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39508>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:50:15 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 31 Jan 2020 14:50:15 +0000
Subject: [issue37304] compiler need support in(de)crement operation or all of
 it should have syntax error.
In-Reply-To: <1580481152.84.0.71725403584.issue37304@roundup.psfhosted.org>
Message-ID: <20200131145010.GD6362@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Please remember that not all Python programmers come from a C background 
where `++n` is a pre-increment operator. Then may have a OOP background 
where the unary `+` and `-` operators can do anything they like.

Making `--obj` or `++obj` a syntax error is a backwards-incompatible 
change that will break people's code. We take backwards compatibility 
seriously. Python is a mature language with millions of users, we don't 
break their code lightly.

As you were told (twice) last year, this change will not be considered 
until you take it to the Python-Ideas mailing list for feedback. If you 
have done this, please post a link to the discussion.

If you get a consensus that the change is a good idea, you need to find 
a core developer to sponsor a PEP, then write the PEP, and ask the 
Steering Council to approve it. Only then will the PR be approved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37304>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:50:49 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 31 Jan 2020 14:50:49 +0000
Subject: [issue39509] Update HTTP status code to follow IANA
Message-ID: <1580482249.3.0.655297807601.issue39509@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na92 at gmail.com>:

status code 103 and 425 is missing.

https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

----------
components: Library (Lib)
messages: 361114
nosy: corona10, martin.panter
priority: normal
severity: normal
status: open
title: Update HTTP status code to follow IANA
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39509>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:51:49 2020
From: report at bugs.python.org (haim)
Date: Fri, 31 Jan 2020 14:51:49 +0000
Subject: [issue39508] no module curses error although i downloaded the module
 - windows 10
In-Reply-To: <1580482082.1.0.922196738704.issue39508@roundup.psfhosted.org>
Message-ID: <1580482309.04.0.742525466252.issue39508@roundup.psfhosted.org>


Change by haim <haim358123 at gmail.com>:


Added file: https://bugs.python.org/file48875/p203.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39508>
_______________________________________

From report at bugs.python.org  Fri Jan 31 09:52:57 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 31 Jan 2020 14:52:57 +0000
Subject: [issue39509] Update HTTP status code to follow IANA
In-Reply-To: <1580482249.3.0.655297807601.issue39509@roundup.psfhosted.org>
Message-ID: <1580482377.74.0.779356706592.issue39509@roundup.psfhosted.org>


Dong-hee Na <donghee.na92 at gmail.com> added the comment:

See the docs that we follow IANA
https://docs.python.org/3/library/http.html?highlight=iana#http-status-codes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39509>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:02:19 2020
From: report at bugs.python.org (Michael Felt)
Date: Fri, 31 Jan 2020 15:02:19 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580482939.71.0.945427742986.issue39502@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

OK. There have been some comments/questions re: PR18282.

a) my PR is missing that PR, seems we just missed each other.

b) when using my patch I took a suggestion from issue39460 to test again:

root at x065:[/home/python/python3-3.9]./python -m test -v test_zipfile -m test_add_file_after_2107 --tempdir /tmp
== CPython 3.9.0a3+ (heads/bpo-39502-dirty:c54fe56362, Jan 30 2020, 15:52:37) [C]
== AIX-3-00C291F54C00-powerpc-64bit big-endian
== cwd: /tmp/test_python_303120
== CPU count: 4
== encodings: locale=ISO8859-1, FS=iso8859-1
0:00:00 Run tests sequentially
0:00:00 [1/1] test_zipfile
test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile) ... ok

----------------------------------------------------------------------

Ran 1 test in 0.257s

OK

== Tests result: SUCCESS ==

1 test OK.

Total duration: 653 ms
Tests result: SUCCESS

Without the --tempdir setting it "skips" to PASS:

root at x065:[/home/python/python3-3.9]./python -m test -v test_zipfile -m test_add_file_after_2107
== CPython 3.9.0a3+ (heads/bpo-39502-dirty:c54fe56362, Jan 30 2020, 15:52:37) [C]
== AIX-3-00C291F54C00-powerpc-64bit big-endian
== cwd: /data/prj/python/python3-3.9/build/test_python_364784
== CPU count: 4
== encodings: locale=ISO8859-1, FS=iso8859-1
0:00:00 Run tests sequentially
0:00:00 [1/1] test_zipfile
test_add_file_after_2107 (test.test_zipfile.StoredTestsWithSourceFile) ... skipped 'Linux VFS/XFS kernel bug detected: mtime_ns=91301504000000000'

----------------------------------------------------------------------

Ran 1 test in 0.010s

OK (skipped=1)

== Tests result: SUCCESS ==

1 test OK.

Total duration: 252 ms
Tests result: SUCCESS

FYI

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:03:44 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 31 Jan 2020 15:03:44 +0000
Subject: [issue39509] Update HTTP status code to follow IANA
In-Reply-To: <1580482249.3.0.655297807601.issue39509@roundup.psfhosted.org>
Message-ID: <1580483024.9.0.623941484795.issue39509@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
keywords: +patch
pull_requests: +17667
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18293

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39509>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:06:43 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 31 Jan 2020 15:06:43 +0000
Subject: [issue37304] compiler need support in(de)crement operation or all of
 it should have syntax error.
In-Reply-To: <1560678383.11.0.0486916958299.issue37304@roundup.psfhosted.org>
Message-ID: <1580483203.82.0.217763056817.issue37304@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Steven, Thank you for your quick comment.

sure, i will keep this bpo stay in `closed` status until enlist the support of core developers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37304>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:08:49 2020
From: report at bugs.python.org (Michael Felt)
Date: Fri, 31 Jan 2020 15:08:49 +0000
Subject: [issue39502] test_zipfile fails on AIX due to time.localtime
In-Reply-To: <1580392297.71.0.07109648974.issue39502@roundup.psfhosted.org>
Message-ID: <1580483329.61.0.45543421848.issue39502@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

p.s., I manually added #18282 to the test, and the results are the same as without - using 64-bit. Will rebuild the 32-bit and try test again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39502>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:11:04 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 31 Jan 2020 15:11:04 +0000
Subject: [issue39509] Update HTTP status code to follow IANA
In-Reply-To: <1580482249.3.0.655297807601.issue39509@roundup.psfhosted.org>
Message-ID: <1580483464.87.0.065640676994.issue39509@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests:  -17667

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39509>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:14:08 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 31 Jan 2020 15:14:08 +0000
Subject: [issue39509] Update HTTP status code to follow IANA
In-Reply-To: <1580482249.3.0.655297807601.issue39509@roundup.psfhosted.org>
Message-ID: <1580483648.65.0.156428820431.issue39509@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
pull_requests: +17668
pull_request: https://github.com/python/cpython/pull/18294

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39509>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:19:52 2020
From: report at bugs.python.org (Philipp Gesang)
Date: Fri, 31 Jan 2020 15:19:52 +0000
Subject: [issue39510] use-after-free in BufferedReader.readinto()
Message-ID: <1580483992.12.0.718198144205.issue39510@roundup.psfhosted.org>


New submission from Philipp Gesang <philipp.gesang at intra2net.com>:

reader = open ("/dev/zero", "rb")
    _void  = reader.read (42)
    reader.close ()
    reader.readinto (bytearray (42)) ### BANG!

Bisected to commit dc469454ec. PR on Github to follow.

----------
messages: 361119
nosy: phg
priority: normal
severity: normal
status: open
title: use-after-free in BufferedReader.readinto()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39510>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:20:45 2020
From: report at bugs.python.org (Philipp Gesang)
Date: Fri, 31 Jan 2020 15:20:45 +0000
Subject: [issue39510] use-after-free in BufferedReader.readinto()
In-Reply-To: <1580483992.12.0.718198144205.issue39510@roundup.psfhosted.org>
Message-ID: <1580484045.27.0.586695446958.issue39510@roundup.psfhosted.org>


Change by Philipp Gesang <philipp.gesang at intra2net.com>:


----------
keywords: +patch
pull_requests: +17669
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18295

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39510>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:23:17 2020
From: report at bugs.python.org (Kent Watsen)
Date: Fri, 31 Jan 2020 15:23:17 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1580484197.75.0.110408090094.issue18233@roundup.psfhosted.org>


Kent Watsen <kent+python at watsen.net> added the comment:

I agree that having both would be best, but there is a world of difference between a must-have (peer_cert_chain) and what seems to be a nice-to-have (authed_peer_cert_chain).

My request for clarification was not that I don't understand bags, etc. (see my first message), but that I don't understand the concrete use case in mind.  That is, when is it that the app-logic would differ because the EE cert validated using one path versus another?

To explain the 'must-have' better, imagine one peer sending [A, B, C], where 'A' is the EE cert, and the other peer having TA [F, E, D], where 'F' is the self-signed root TA and 'D' is the Issuer that signed 'C'.  The complete chain is [A-F] and this is what the SSL-level code will use during the handshake.  But post-handshake, without peer_chain_cert(), there is NO WAY for the app-logic to create a valid chain.  This is broken, for the reason mentioned in my first message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:33:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Jan 2020 15:33:35 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
Message-ID: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The long-term goal of the PEP 554 is to run two Python interpreters in parallel. To achieve this goal, no object must be shared between two interpreters. See for example my article "Pass the Python thread state explicitly" which gives a longer rationale:
https://vstinner.github.io/cpython-pass-tstate.html

In bpo-38858, I modified Objects/longobject.c to have per-interpreter small integer singletons: commit 630c8df5cf126594f8c1c4579c1888ca80a29d59.

This issue is about other singletons like None or Py_True which are currently shared between two interpreters.

I propose to add new functions. Example for None:

* Py_GetNone(): return a *borrowed* reference to the None singleton (similar to existing Py_None macro)
* Py_GetNoneRef(): return a *strong* reference to the None singleton (similar to "Py_INCREF(Py_None); return Py_None;" and Py_RETURN_NONE macro)

And add PyInterpreterState.none field: strong reference to the per-interpreter None object.


We should do that for each singletons:

* None (Py_None)
* True (Py_True)
* False (Py_False)
* Ellipsis (Py_Ellipsis)


GIL issue
=========

Py_GetNone() would look like:

PyObject* Py_GetNone(void)
{ return _PyThreadState_GET()->interp->none; }

Problem: _PyThreadState_GET() returns NULL if the caller function doesn't hold the GIL.

Using the Python C API when the GIL is not held is a violation of the API: it is not supported. But it worked previously.

One solution is to fail with an assertion error (abort the process) in debug mode, and let Python crash in release mode.

Another option is to only fail with an assertion error in debug mode in Python 3.9. In Python 3.9, Py_GetNone() would use PyGILState_GetThisThreadState() function which works even when the GIL is released. In Python 3.10, we would switch to _PyThreadState_GET() and so crash in release mode.

One concrete example of such issue can be found in the multiprocessing C code, in semlock_acquire():

            Py_BEGIN_ALLOW_THREADS
            if (timeout_obj == Py_None) {
                res = sem_wait(self->handle);
            }
            else {
                res = sem_timedwait(self->handle, &deadline);
            }
            Py_END_ALLOW_THREADS

Py_None is accessed when the GIL is released.

----------
components: Interpreter Core
messages: 361121
nosy: vstinner
priority: normal
severity: normal
status: open
title: [subinterpreters] Per-interpreter singletons (None, True, False, etc.)
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:37:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Jan 2020 15:37:51 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580485071.93.0.451427251255.issue39511@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +17671
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18296

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Jan 31 10:48:24 2020
From: report at bugs.python.org (hai shi)
Date: Fri, 31 Jan 2020 15:48:24 +0000
Subject: [issue37304] compiler need support in(de)crement operation or all of
 it should have syntax error.
In-Reply-To: <1560678383.11.0.0486916958299.issue37304@roundup.psfhosted.org>
Message-ID: <1580485704.77.0.248661837297.issue37304@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +17672
pull_request: https://github.com/python/cpython/pull/18297

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37304>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:05:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Jan 2020 16:05:04 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580486704.64.0.66161006583.issue39511@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17673
pull_request: https://github.com/python/cpython/pull/18298

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:14:26 2020
From: report at bugs.python.org (Aurora)
Date: Fri, 31 Jan 2020 16:14:26 +0000
Subject: [issue39455] Update the documentation for the linecache module
In-Reply-To: <1579984052.28.0.0961825166353.issue39455@roundup.psfhosted.org>
Message-ID: <1580487266.23.0.935497347398.issue39455@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
title: Update the documentation for linecache module -> Update the documentation for the linecache module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39455>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:15:01 2020
From: report at bugs.python.org (Aurora)
Date: Fri, 31 Jan 2020 16:15:01 +0000
Subject: [issue39314] (readline) Autofill the closing parenthesis during
 auto-completion for functions which accept no arguments at all
In-Reply-To: <1578846697.93.0.381295981609.issue39314@roundup.psfhosted.org>
Message-ID: <1580487301.58.0.0866219822558.issue39314@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
title: Autofill the closing paraenthesis during auto-completion for functions which accept no arguments at all -> (readline) Autofill the closing parenthesis during auto-completion for functions which accept no arguments at all

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39314>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:19:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 31 Jan 2020 16:19:11 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580487551.2.0.653867092505.issue39511@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +eric.snow, nanjekyejoannah, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:24:06 2020
From: report at bugs.python.org (Aurora)
Date: Fri, 31 Jan 2020 16:24:06 +0000
Subject: [issue39455] Update the documentation for the linecache module
In-Reply-To: <1579984052.28.0.0961825166353.issue39455@roundup.psfhosted.org>
Message-ID: <1580487846.06.0.960487219386.issue39455@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39455>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:43:26 2020
From: report at bugs.python.org (Aurora)
Date: Fri, 31 Jan 2020 16:43:26 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580489006.67.0.863656991547.issue39468@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
pull_requests: +17674
pull_request: https://github.com/python/cpython/pull/18299

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:44:11 2020
From: report at bugs.python.org (Aurora)
Date: Fri, 31 Jan 2020 16:44:11 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580489051.48.0.546041228082.issue39468@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
pull_requests: +17675
pull_request: https://github.com/python/cpython/pull/39468

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:44:52 2020
From: report at bugs.python.org (Aurora)
Date: Fri, 31 Jan 2020 16:44:52 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580489092.96.0.0924559769638.issue39468@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
pull_requests:  -17589

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:45:00 2020
From: report at bugs.python.org (Aurora)
Date: Fri, 31 Jan 2020 16:45:00 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580489100.31.0.285241016233.issue39468@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
pull_requests:  -17674

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:45:07 2020
From: report at bugs.python.org (Aurora)
Date: Fri, 31 Jan 2020 16:45:07 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580489107.68.0.953122829335.issue39468@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
pull_requests:  -17675

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:45:15 2020
From: report at bugs.python.org (Aurora)
Date: Fri, 31 Jan 2020 16:45:15 +0000
Subject: [issue39468] .python_history write permission improvements
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580489115.72.0.569879452905.issue39468@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
pull_requests: +17677
pull_request: https://github.com/python/cpython/pull/18299

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:45:44 2020
From: report at bugs.python.org (Aurora)
Date: Fri, 31 Jan 2020 16:45:44 +0000
Subject: [issue39468] Improved the site module's permission handling while
 writing .python_history
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580489144.31.0.149616649072.issue39468@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
title: .python_history write permission improvements -> Improved the site module's permission handling while writing .python_history

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Fri Jan 31 11:46:01 2020
From: report at bugs.python.org (Aurora)
Date: Fri, 31 Jan 2020 16:46:01 +0000
Subject: [issue39468] Improved the site module's permission handling while
 writing .python_history
In-Reply-To: <1580154412.97.0.35138425226.issue39468@roundup.psfhosted.org>
Message-ID: <1580489161.96.0.901728334163.issue39468@roundup.psfhosted.org>


Change by Aurora <auroralanes at pm.me>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39468>
_______________________________________

From report at bugs.python.org  Fri Jan 31 12:11:18 2020
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 31 Jan 2020 17:11:18 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580490678.16.0.883344309712.issue39511@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

Would it not suffice to just make the singletons "immortal"?

Without affecting the hotpaths that are Py_INCREF and Py_DECREF, changing _Py_Dealloc to test for objects with a "special" destructor could be used:

    destructor dealloc = Py_TYPE(op)->tp_dealloc;
    if (dealloc == _Py_SingletonSentinel) {
        /* reset refcnt so as to not return here too often */
        op->ob_refcnt = PY_SSIZE_T_MAX;
    }
    else {
        (*dealloc)(op);
    }

Even in the presence of multiple mutating threads, the object cannot be destroyed.  Worst case, they all call _Py_Dealloc.

----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Jan 31 12:24:57 2020
From: report at bugs.python.org (Anselmo Melo)
Date: Fri, 31 Jan 2020 17:24:57 +0000
Subject: [issue39503] [security][CVE-2020-8492] Denial of service in
 urllib.request.AbstractBasicAuthHandler
In-Reply-To: <1580397089.41.0.564267118679.issue39503@roundup.psfhosted.org>
Message-ID: <1580491497.5.0.67360437916.issue39503@roundup.psfhosted.org>


Change by Anselmo Melo <anselmo.melo at intel.com>:


----------
nosy: +Anselmo Melo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39503>
_______________________________________

From report at bugs.python.org  Fri Jan 31 12:38:36 2020
From: report at bugs.python.org (Ram Rachum)
Date: Fri, 31 Jan 2020 17:38:36 +0000
Subject: [issue39280] Don't allow datetime parsing to accept non-Ascii digits
In-Reply-To: <1578604255.88.0.113689913662.issue39280@roundup.psfhosted.org>
Message-ID: <1580492316.97.0.512826530956.issue39280@roundup.psfhosted.org>


Ram Rachum <ram at rachum.com> added the comment:

Hi guys,

Can we please have a decision on whether we want to move forward with this issue or not? I have a patch in the PR, and I'll be happy to continue working on it, or close this issue if that's the decision.


Thanks,
Ram.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39280>
_______________________________________

From report at bugs.python.org  Fri Jan 31 13:26:08 2020
From: report at bugs.python.org (Malte Forkel)
Date: Fri, 31 Jan 2020 18:26:08 +0000
Subject: [issue39512] expat parser not xml 1.1 (breaks xmlrpclib) - still
Message-ID: <1580495168.43.0.888386577415.issue39512@roundup.psfhosted.org>


New submission from Malte Forkel <malte.forkel at berlin.de>:

xmlrpc uses expat, which is not XML 1.1 compliant. Therefore, when transferring text, some characters which a valid according to the XML-RPC specification (http://xmlrpc.com/spec.md) will trigger expat to raise xml.parsers.expat.ExpatError: not well-formed (invalid token) exceptions.

Issue 11804 (https://bugs.python.org/issue11804) which reported this problem has been closed almost 20 years ago, referencing an expat bug report for XML 1.1 support. That bug report is still open and there is no current plan to support XML 1.1 in expat (https://github.com/libexpat/libexpat/issues/378#issuecomment-578914067).

I would like to suggest to replace expat as the default parser in xmlrpc or at least make it easier to override the default (see https://bugs.python.org/issue6701).

----------
components: XML
messages: 361124
nosy: mforkel
priority: normal
severity: normal
status: open
title: expat parser not xml 1.1 (breaks xmlrpclib) - still

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39512>
_______________________________________

From report at bugs.python.org  Fri Jan 31 14:15:26 2020
From: report at bugs.python.org (Sandeep)
Date: Fri, 31 Jan 2020 19:15:26 +0000
Subject: [issue39513] NameError: name 'open' is not defined
Message-ID: <1580498126.56.0.466830375597.issue39513@roundup.psfhosted.org>


Change by Sandeep <kthakur.nand at gmail.com>:


----------
components: Library (Lib)
nosy: Sandeep
priority: normal
severity: normal
status: open
title: NameError: name 'open' is not defined
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39513>
_______________________________________

From report at bugs.python.org  Fri Jan 31 14:18:57 2020
From: report at bugs.python.org (Sandeep)
Date: Fri, 31 Jan 2020 19:18:57 +0000
Subject: [issue39513] NameError: name 'open' is not defined
Message-ID: <1580498337.58.0.0606728460892.issue39513@roundup.psfhosted.org>


New submission from Sandeep <kthakur.nand at gmail.com>:

Hi 
   I wrote a python script which gets file from other server and it works fine till the time I don't introduces logging feature to it. 
Please advice how to fix below

This is the code I am using for logging '

import logging
logging.basicConfig(filename=localLogfile, level=logging.DEBUG)

--Error Message 

Traceback (most recent call last):
  File "/d01/python3/lib64/python3.6/site-packages/pysftp/__init__.py", line 1013, in __del__
  File "/d01/python3/lib64/python3.6/site-packages/pysftp/__init__.py", line 785, in close
  File "/d01/python3/lib64/python3.6/site-packages/paramiko/sftp_client.py", line 194, in close
  File "/d01/python3/lib64/python3.6/site-packages/paramiko/sftp_client.py", line 185, in _log
  File "/d01/python3/lib64/python3.6/site-packages/paramiko/sftp.py", line 158, in _log
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/logging/__init__.py", line 1372, in log
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/logging/__init__.py", line 1442, in _log
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/logging/__init__.py", line 1452, in handle
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/logging/__init__.py", line 1514, in callHandlers
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/logging/__init__.py", line 863, in handle
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/logging/__init__.py", line 1069, in emit
  File "/opt/rh/rh-python36/root/usr/lib64/python3.6/logging/__init__.py", line 1059, in _open
NameError: name 'open' is not defined

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39513>
_______________________________________

From report at bugs.python.org  Fri Jan 31 14:30:00 2020
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Fri, 31 Jan 2020 19:30:00 +0000
Subject: [issue39350] Remove deprecated fractions.gcd()
In-Reply-To: <1579162424.21.0.493196334096.issue39350@roundup.psfhosted.org>
Message-ID: <1580499000.84.0.77530880401.issue39350@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

Naively implementing this code, I'd use isinstance(numerator, int) over type(numerator) is int. Is that strict type check really needed?

I could not find anywhere whether numerator and denominator of numbers.Rational need to be numbers.Integral. I would expect so, however this is not written in the documentation of numbers.Rational. If that's the case, I think checking it for being numbers.Integral and failing hard if not is a reasonable thing to do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39350>
_______________________________________

From report at bugs.python.org  Fri Jan 31 14:41:25 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 31 Jan 2020 19:41:25 +0000
Subject: [issue39513] NameError: name 'open' is not defined
In-Reply-To: <1580498337.58.0.0606728460892.issue39513@roundup.psfhosted.org>
Message-ID: <1580499685.95.0.381481209657.issue39513@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also https://bugs.python.org/issue26789

----------
nosy: +vinay.sajip, xtreak
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39513>
_______________________________________

From report at bugs.python.org  Fri Jan 31 14:57:51 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jan 2020 19:57:51 +0000
Subject: [issue39391] Run-dependent Pydoc output for functions default
 parameters
In-Reply-To: <1579475037.48.0.632958566945.issue39391@roundup.psfhosted.org>
Message-ID: <1580500671.94.0.242866240385.issue39391@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

repr(f2) is not 'non-deterministic'.  If one runs it again for the same function object, one gets the same answer. It only changes when one starts over and creates a new function object with the same name but (usually) different id.

I think it appropriate that the default object representation include the object id.  It may help with debugging or other operations.

I agree that pydoc output with run-dependent ids may not be suitable for storage in version control.  Either remove or normalize them yourself or ask the pydoc developers to add an option to improve its output.

Reclosing.

----------
nosy: +terry.reedy
resolution:  -> third party
status: open -> closed
title: Nondeterministic Pydoc output on functions that have functions as default parameters -> Run-dependent Pydoc output for functions default parameters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39391>
_______________________________________

From report at bugs.python.org  Fri Jan 31 15:05:31 2020
From: report at bugs.python.org (Sandeep)
Date: Fri, 31 Jan 2020 20:05:31 +0000
Subject: [issue26789] Please do not log during shutdown
In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za>
Message-ID: <1580501131.57.0.706164297235.issue26789@roundup.psfhosted.org>


Sandeep <kthakur.nand at gmail.com> added the comment:

I did import aiohttp and called function sys.is_finalizing() just before 
logging.basicConfig but still the same error.

Has  logging.basicConfig worked in past ? If yes what  additional package I need to add

Thanks

----------
nosy: +Sandeep

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26789>
_______________________________________

From report at bugs.python.org  Fri Jan 31 15:07:22 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 31 Jan 2020 20:07:22 +0000
Subject: [issue37224] test__xxsubinterpreters fails randomly
In-Reply-To: <1560214681.61.0.906498246375.issue37224@roundup.psfhosted.org>
Message-ID: <1580501242.24.0.437824569279.issue37224@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f03a8f8d5001963ad5b5b28dbd95497e9cc15596 by Kyle Stanley in branch 'master':
bpo-37224: Improve test__xxsubinterpreters.DestroyTests (GH-18058)
https://github.com/python/cpython/commit/f03a8f8d5001963ad5b5b28dbd95497e9cc15596


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37224>
_______________________________________

From report at bugs.python.org  Fri Jan 31 15:28:17 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jan 2020 20:28:17 +0000
Subject: [issue39480] referendum reference is needlessly annoying
In-Reply-To: <1580231234.47.0.658599858582.issue39480@roundup.psfhosted.org>
Message-ID: <1580502497.2.0.0273272292652.issue39480@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I concur with Steven and Raymond.  The 2016 Brexit votes were Leave 17.4 million and Remain 16.1 million.  No resemblence to the hypothetical example.  I think that this should be closed as 'not a bug'.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39480>
_______________________________________

From report at bugs.python.org  Fri Jan 31 15:30:57 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Jan 2020 20:30:57 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580502657.51.0.112272897732.issue39484@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Fri Jan 31 15:45:42 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jan 2020 20:45:42 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580503542.81.0.453879787238.issue39484@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Fri Jan 31 15:50:48 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jan 2020 20:50:48 +0000
Subject: [issue39507] http library missing HTTP status code 418 "I'm a teapot"
In-Reply-To: <1580477561.46.0.283786859287.issue39507@roundup.psfhosted.org>
Message-ID: <1580503848.24.0.510245377525.issue39507@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

https://en.wikipedia.org/wiki/Hyper_Text_Coffee_Pot_Control_Protocol#Save_418_movement

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39507>
_______________________________________

From report at bugs.python.org  Fri Jan 31 15:59:38 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 31 Jan 2020 20:59:38 +0000
Subject: [issue29249] Pathlib glob ** bug
In-Reply-To: <1484216394.04.0.57434547579.issue29249@psf.upfronthosting.co.za>
Message-ID: <1580504378.3.0.68918108058.issue29249@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29249>
_______________________________________

From report at bugs.python.org  Fri Jan 31 16:36:43 2020
From: report at bugs.python.org (Carlos ESTEVES)
Date: Fri, 31 Jan 2020 21:36:43 +0000
Subject: [issue39514] http://sphinx.pocoo.org/
Message-ID: <1580506603.75.0.50119765059.issue39514@roundup.psfhosted.org>


New submission from Carlos ESTEVES <carlos.em.esteves at gmail.com>:

Hi,

"Sphinx" link is break on webpage: https://docs.python.org/3/

See:
<a href="http://sphinx.pocoo.org/">Sphinx</a>

Thank You

----------
assignee: docs at python
components: Documentation
messages: 361135
nosy: cesteves, docs at python
priority: normal
severity: normal
status: open
title: http://sphinx.pocoo.org/

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39514>
_______________________________________

From report at bugs.python.org  Fri Jan 31 17:02:44 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 31 Jan 2020 22:02:44 +0000
Subject: [issue16651] Find out what stdlib modules lack a pure Python
 implementation
In-Reply-To: <1355078393.91.0.564166411172.issue16651@psf.upfronthosting.co.za>
Message-ID: <1580508164.86.0.515438828806.issue16651@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16651>
_______________________________________

From report at bugs.python.org  Fri Jan 31 17:13:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 31 Jan 2020 22:13:40 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580508820.65.0.00131131251216.issue39484@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Fri Jan 31 18:51:14 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 31 Jan 2020 23:51:14 +0000
Subject: [issue39509] Update HTTP status code to follow IANA
In-Reply-To: <1580482249.3.0.655297807601.issue39509@roundup.psfhosted.org>
Message-ID: <1580514674.94.0.767160219029.issue39509@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na92 at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39509>
_______________________________________

From report at bugs.python.org  Fri Jan 31 19:07:11 2020
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 01 Feb 2020 00:07:11 +0000
Subject: [issue37130] pathlib.Path.with_name() handles '.' and '..'
 inconsistently
In-Reply-To: <1559438292.33.0.601764456145.issue37130@roundup.psfhosted.org>
Message-ID: <1580515631.56.0.707170401972.issue37130@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
assignee: brett.cannon -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37130>
_______________________________________

From report at bugs.python.org  Fri Jan 31 19:07:05 2020
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 01 Feb 2020 00:07:05 +0000
Subject: [issue37130] pathlib.Path.with_name() handles '.' and '..'
 inconsistently
In-Reply-To: <1559438292.33.0.601764456145.issue37130@roundup.psfhosted.org>
Message-ID: <1580515625.07.0.869088013885.issue37130@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

So I tried making pathlib.PurePath handle "." more like ".." and tests started failing all over the place in test_pathlib, which means it would be a change in semantics and could start silently breaking people as most of the checks are for specific exceptions.

So the next question is where is '..' being mishandled? It might be possible and better to tighten up how '..' is treated than try to make '.' suddenly be treated in a weaker way.

----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37130>
_______________________________________

From report at bugs.python.org  Fri Jan 31 19:26:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 00:26:17 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580516777.59.0.422372978412.issue39511@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7dc140126e918cc7c6e65aea321b7255f0020798 by Victor Stinner in branch 'master':
bpo-39511: Fix multiprocessing semlock_acquire() (GH-18298)
https://github.com/python/cpython/commit/7dc140126e918cc7c6e65aea321b7255f0020798


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Jan 31 19:30:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 00:30:57 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580517057.49.0.13192433757.issue39511@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Would it not suffice to just make the singletons "immortal"?

The problem is to make Py_INCREF/Py_DECREF efficient. Last time someone tried to use an atomic variable for ob_refcnt, it was 20% slower if I recall correctly. If many threads start to update such atomic variable, the CPU cacheline of common singletons like None, True and False can quickly become a performance bottleneck.

On the other side, if each interpreter has its own objects, there is no need to protect ob_refcnt, the interpreter lock protects it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Jan 31 19:59:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 00:59:08 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580518748.47.0.557874428735.issue39484@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

>>> a / 10**9 <= b
    False

Try to use a/1e9 <= b.

--

The C code to get the system clock is the same for time.time() and time.time_ns(). It's only the conversion of the result which is different:

static PyObject *
time_time(PyObject *self, PyObject *unused)
{
    _PyTime_t t = _PyTime_GetSystemClock();
    return _PyFloat_FromPyTime(t);
}

static PyObject *
time_time_ns(PyObject *self, PyObject *unused)
{
    _PyTime_t t = _PyTime_GetSystemClock();
    return _PyTime_AsNanosecondsObject(t);
}

where _PyTime_t is int64_t: 64-bit signed integer.


Conversions:

static PyObject*
_PyFloat_FromPyTime(_PyTime_t t)
{
    double d = _PyTime_AsSecondsDouble(t);
    return PyFloat_FromDouble(d);
}


double
_PyTime_AsSecondsDouble(_PyTime_t t)
{
    /* volatile avoids optimization changing how numbers are rounded */
    volatile double d;

    if (t % SEC_TO_NS == 0) {
        _PyTime_t secs;
        /* Divide using integers to avoid rounding issues on the integer part.
           1e-9 cannot be stored exactly in IEEE 64-bit. */
        secs = t / SEC_TO_NS;
        d = (double)secs;
    }
    else {
        d = (double)t;
        d /= 1e9;
    }
    return d;
}

PyObject *
_PyTime_AsNanosecondsObject(_PyTime_t t)
{
    Py_BUILD_ASSERT(sizeof(long long) >= sizeof(_PyTime_t));
    return PyLong_FromLongLong((long long)t);
}

In short, time.time() = float(time.time_ns()) / 1e9.

--

The problem can be reproduced in Python:

>>> a=1580301619906185300
>>> b=a/1e9
>>> a / 10**9 <= b
False

I added time.time_ns() because we loose precision if you care about nanosecond resolution, with such "large number". float has a precision around 238 nanoseconds:

>>> import math; ulp=math.ulp(b)
>>> ulp
2.384185791015625e-07
>>> "%.0f +- %.0f" % (b*1e9, ulp*1e9)
'1580301619906185216 +- 238'

int/int and int/float don't give the same result:

>>> a/10**9
1580301619.9061854
>>> a/1e9
1580301619.9061852

I'm not sure which one is "correct". To understand the issue, you can use the next math.nextafter() function to get the next floating point towards -inf:

>>> a/10**9
1580301619.9061854
>>> a/1e9
1580301619.9061852
>>> math.nextafter(a/10**9, -math.inf)
1580301619.9061852
>>> math.nextafter(a/1e9, -math.inf)
1580301619.906185

Handling floating point numbers are hard.

Why don't use only use integers? :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Fri Jan 31 20:01:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 01:01:18 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580518878.18.0.461200779369.issue39484@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-39277 which is similar issue. I proposed a fix which uses nextafter():
https://github.com/python/cpython/pull/17933

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Fri Jan 31 20:10:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 01:10:45 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580519445.11.0.282787732766.issue39484@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Another way to understand the problem: nanosecond (int) => seconds (float) => nanoseconds (int) roundtrip looses precison.

>>> a=1580301619906185300
>>> a/1e9*1e9
1.5803016199061852e+18
>>> b=int(a/1e9*1e9)
>>> b
1580301619906185216
>>> a - b
84

The best would be to add a round parameter to _PyTime_AsSecondsDouble(), but I'm not sure how to implement it.

The following rounding mode is used to read a clock:

    /* Round towards minus infinity (-inf).
       For example, used to read a clock. */
    _PyTime_ROUND_FLOOR=0,

_PyTime_ROUND_FLOOR is used in time.clock_settime(), time.gmtime(), time.localtime() and time.ctime() functions: to round input arguments.

time.time(), time.monotonic() and time.perf_counter() converts _PyTime_t to float using _PyTime_AsSecondsDouble() (which currently has no round parameter) for their output.

See also my rejected PEP 410 ;-)

--

One way to solve this issue is to document how to compare time.time() and time.time_ns() timestamps in a reliable way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Fri Jan 31 20:14:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 01:14:37 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580519677.73.0.0829520443209.issue39484@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

By the way, I wrote an article about the history on how Python rounds time... https://vstinner.github.io/pytime.html

I also wrote two articles about nanoseconds in Python:

* https://vstinner.github.io/python37-pep-564-nanoseconds.html
* https://vstinner.github.io/python37-perf-counter-nanoseconds.html

Oh and I forgot the main one: PEP 564 :-)

"Example 2: compare times with different resolution" sounds like this issue.

https://www.python.org/dev/peps/pep-0564/#example-2-compare-times-with-different-resolution

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Fri Jan 31 20:17:49 2020
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 01 Feb 2020 01:17:49 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580519869.55.0.195288796897.issue39484@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

I don't think this is fixable, because it's not exactly a bug.  The problem is we're running out of bits.  In converting the time around, we've lost some precision.  So the times that come out of time.time() and time.time_ns() should not be considered directly comparable.

Both functions, time.time() and time.time_ns(), call the same underlying function to get the current time.  That function is_PyTime_GetSystemClock(); it returns nanoseconds since the 1970 epoch, stored in an int64.  Each function then simply converts that time into its return format and returns that.

In the case of time.time_ns(), it loses no precision whatsoever.  In the case of time.time(), it (usually) converts to double and divides by 1e9, which is implicitly floor rounding.

Back-of-the-envelope math here: An IEEE double has 53 bits of resolution for the mantissa, not counting the leading 1. The current time in seconds since the 1970 epoch uses about 29 bits of those 53 bits.  That leaves 24 bits for the fractional second.  But you'd need 30 bits to render all one billion fractional values.  We're six bits short.

Unless anybody has an amazing suggestion about how to ameliorate this situation, I think we should close this as wontfix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Fri Jan 31 20:18:55 2020
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 01 Feb 2020 01:18:55 +0000
Subject: [issue39484] time_ns() and time() cannot be compared on windows
In-Reply-To: <1580302965.78.0.0683890137903.issue39484@roundup.psfhosted.org>
Message-ID: <1580519935.48.0.291766971222.issue39484@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

(Oh, wow, Victor, you wrote all that while I was writing my reply. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39484>
_______________________________________

From report at bugs.python.org  Fri Jan 31 20:30:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 01:30:31 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580520631.94.0.251867227402.issue39511@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4d96b4635aeff1b8ad41d41422ce808ce0b971c8 by Victor Stinner in branch 'master':
bpo-39511: PyThreadState_Clear() calls on_delete (GH-18296)
https://github.com/python/cpython/commit/4d96b4635aeff1b8ad41d41422ce808ce0b971c8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Jan 31 20:32:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 01:32:29 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580520749.48.0.483867237254.issue39511@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +17678
pull_request: https://github.com/python/cpython/pull/18301

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Jan 31 20:34:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 01 Feb 2020 01:34:20 +0000
Subject: [issue39511] [subinterpreters] Per-interpreter singletons (None, True,
 False, etc.)
In-Reply-To: <1580484815.27.0.407070570821.issue39511@roundup.psfhosted.org>
Message-ID: <1580520860.3.0.681904940255.issue39511@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

PR 18301 is a WIP showing my intent. I'm not sure if it would be possible to land such change right now in Python. It has different drawbacks described in my previous messages. I don't know the impact on performance neither.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39511>
_______________________________________

From report at bugs.python.org  Fri Jan 31 20:39:48 2020
From: report at bugs.python.org (Isaac Muse)
Date: Sat, 01 Feb 2020 01:39:48 +0000
Subject: [issue29249] Pathlib glob ** bug
In-Reply-To: <1484216394.04.0.57434547579.issue29249@psf.upfronthosting.co.za>
Message-ID: <1580521188.51.0.879108686902.issue29249@roundup.psfhosted.org>


Isaac Muse <faceless.server1 at gmail.com> added the comment:

I think the idea of adding a globmatch function is a decent idea.

That is what I did in a library I wrote to get more out of glob than what Python offered out of the box: https://facelessuser.github.io/wcmatch/pathlib/#purepathglobmatch. 

Specifically the differences are globmatch is just a pure match of a path, it doesn't do the implied `**` at the beginning of a pattern like match does. While it doesn't enable `**` by default, such features are controlled by flags

>>> pathlib.Path("a/b/c/d/e.txt").match('a/*/**/*', flags=pathlib.GLOBSTAR)
True

This isn't to promote my library, but more to say, as a user, I found such functionality worth adding. I think it would be generally nice to have such functionality in some form in Python by default. Maybe something called `globmatch` that offers that could be worthwhile.

----------
nosy: +Isaac Muse

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29249>
_______________________________________

From report at bugs.python.org  Fri Jan 31 22:18:39 2020
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 01 Feb 2020 03:18:39 +0000
Subject: [issue39514] http://sphinx.pocoo.org/
In-Reply-To: <1580506603.75.0.50119765059.issue39514@roundup.psfhosted.org>
Message-ID: <1580527119.17.0.494666194786.issue39514@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

Thanks for the report. The link has already been fixed in https://github.com/python/python-docs-theme/commit/fc9f203dd79587c8aed2b822cf7401518cd65bb5 I think it will be fixed once the new version of the theme is released.

We can discuss the details over at python/python-docs-theme. Closing this issue for now.

----------
nosy: +berker.peksag, zach.ware
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39514>
_______________________________________

From report at bugs.python.org  Fri Jan 31 22:45:08 2020
From: report at bugs.python.org (=?utf-8?b?5b6Q5b27?=)
Date: Sat, 01 Feb 2020 03:45:08 +0000
Subject: [issue39515] pathlib won't strip "\n" in path
Message-ID: <1580528708.47.0.815684087896.issue39515@roundup.psfhosted.org>


New submission from ?? <chrisxuche at gmail.com>:

Pathlib won't strip "\n" in path. Of course, "\n" should exist in a legal path.
For example:

>>>a=pathlib.Path(pathlib.Path("C:/Program Files/\n"),"./JetBrains/\n")
>>>a
WindowsPath('C:/Program Files/\n/JetBrains/\n')

----------
components: Library (Lib)
messages: 361149
nosy: ??
priority: normal
severity: normal
status: open
title: pathlib won't strip "\n" in path
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39515>
_______________________________________