[issue31904] Python should support VxWorks RTOS

[Peixing Xin]

Change by Peixing Xin :


--
pull_requests: +22676
pull_request: https://github.com/python/cpython/pull/23815

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41804] test_epoll fails test_control_and_wait() randomly on aarch64 RHEL8 Refleaks 3.9

[STINNER Victor]

STINNER Victor  added the comment:

Oh, test_epoll failed on 3.9. So I backported my change to 3.8 and 3.9, to see 
if it helps or not.

s390x RHEL8 Refleaks 3.9:
https://buildbot.python.org/all/#builders/326/builds/159

Traceback (most recent call last):
  File 
"/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z.refleak/build/Lib/test/test_epoll.py",
 line 199, in test_control_and_wait
self.assertEqual(events, expected)
AssertionError: Lists differ: [(5, 5)] != [(4, 5), (5, 5)]

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41804] test_epoll fails test_control_and_wait() randomly on aarch64 RHEL8 Refleaks 3.9

[miss-islington]

Change by miss-islington :


--
pull_requests: +22675
pull_request: https://github.com/python/cpython/pull/23814

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41804] test_epoll fails test_control_and_wait() randomly on aarch64 RHEL8 Refleaks 3.9

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +22674
pull_request: https://github.com/python/cpython/pull/23813

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42651] Recursive traceback crashes Python Interpreter

[Xinmeng Xia]

Change by Xinmeng Xia :


--
title: Title: Recursive traceback crashes  Python Interpreter -> Recursive 
traceback crashes  Python Interpreter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41960] Add globalns and localns to the inspect.signature and inspect.Signature.from_callable

[Guido van Rossum]

Guido van Rossum  added the comment:

It's been a while, I've lost context for this idea. What problem are you trying 
to solve here? Are there issues where people have reported problems that this 
would allow them to solve?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17140] Document multiprocessing.pool.ThreadPool

[Matt Wozniski]

Change by Matt Wozniski :


--
keywords: +patch
nosy: +godlygeek
nosy_count: 7.0 -> 8.0
pull_requests: +22673
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23812

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42659] Objects of uname_result Class Cannot be Successfully Pickled

[Jason R. Coombs]

Change by Jason R. Coombs :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42664] strptime(%c) fails to parse the output of strftime(%c)

[Eric V. Smith]

Change by Eric V. Smith :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42664] strptime(%c) fails to parse the output of strftime(%c)

[Eric V. Smith]

Eric V. Smith  added the comment:

You have the parameters to strptime backward.

>>> datetime.datetime.strptime(datetime.datetime.now().strftime("%c"), "%c")
datetime.datetime(2020, 12, 16, 20, 51, 38)

--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42090] zipfile.Path.joinpath API inconsistent with pathlib.Path.joinpath

[Jason R. Coombs]

Change by Jason R. Coombs :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41478] Empty representation of AssertionError

[Irit Katriel]

Change by Irit Katriel :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42664] strptime(%c) fails to parse the output of strftime(%c)

[sds]

New submission from sds :

>>> import datetime, locale
>>> locale.getlocale()
('en_US', 'UTF-8')
>>> datetime.datetime.strptime("%c",datetime.datetime.now().strftime("%c"))
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.8/_strptime.py", line 568, in _strptime_datetime
tt, fraction, gmtoff_fraction = _strptime(data_string, format)
  File "/usr/lib/python3.8/_strptime.py", line 349, in _strptime
raise ValueError("time data %r does not match format %r" %
ValueError: time data '%c' does not match format 'Wed Dec 16 18:44:27 2020'

--
components: Library (Lib)
messages: 383217
nosy: sam-s
priority: normal
severity: normal
status: open
title: strptime(%c) fails to parse the output of strftime(%c)
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +22671
pull_request: https://github.com/python/cpython/pull/23811

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Daniel Hahler]

Daniel Hahler  added the comment:

Brett, thanks for the reference.

I've found 
https://discuss.python.org/t/coverage-report-in-github-ci-for-standard-library/2836/11,
 and https://bugs.python.org/issue40993 through it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Daniel Hahler]

Change by Daniel Hahler :


--
nosy: +blueyed -blueyed2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42659] Objects of uname_result Class Cannot be Successfully Pickled

[CrocoDuck]

CrocoDuck  added the comment:

Hi, I somehow missed the other issue while searching for something 
similar to this, sorry about that.

The main issue is that files pickled with python 3.9.0 cannot be read 
back by using python 3.9.0 if they contain a `uname_result` object.

As for expecting pickle to work across different versions: I did not 
actually think about that. In the original message I mentioned python 
3.8.5 as I noticed this issue did not happen in python 3.8.5, so I 
though it was useful information. To my (hopefully correct) 
understanding if a python version supports the same protocol that was 
used to create the pickle file then it is expected to work. For example 
I have observed that files containing `uname_result` objects pickled 
with python 3.7.6 are still readable with python 3.8.5. As far as I 
understand this is the expected behavior.

On 16/12/2020 22:08, Jason R. Coombs wrote:
> Jason R. Coombs  added the comment:
>
> The PR for the related issue does address pickling. Do you expect pickles to 
> work across Python versions?
>
> --
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42659] Objects of uname_result Class Cannot be Successfully Pickled

[Jason R. Coombs]

Jason R. Coombs  added the comment:

The PR for the related issue does address pickling. Do you expect pickles to 
work across Python versions?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37961] Tracemalloc traces do not include original stack trace length

[miss-islington]

miss-islington  added the comment:


New changeset 78062e07bc7c3b47ffdcdec786b259dda376370c by Miss Islington (bot) 
in branch '3.9':
bpo-37961: Fix regression in tracemalloc.Traceback.__repr__ (GH-23805)
https://github.com/python/cpython/commit/78062e07bc7c3b47ffdcdec786b259dda376370c


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Brett Cannon]

Brett Cannon  added the comment:

Your question is best directed at https://discuss.python.org/c/core-workflow/8, 
Daniel.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42125] linecache cannot get source for the __main__ module with a custom loader

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42415] python3.lib in Python3.9.0 Windows distribution does not contain PyObject_CallNoArgs symbol

[STINNER Victor]

STINNER Victor  added the comment:

Thanks David Hewitt for the bug report, and Zackery Spytz for your fix!

3.9 fix:

commit 166286849048eccadecf02b242dbc4042b780944
Author: Victor Stinner 
Date:   Wed Dec 16 22:41:47 2020 +0100

Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)

Add the following symbols to python3dll.c:

* PyFrame_GetCode (bpo-40421)
* PyFrame_GetLineNumber (bpo-40421)
* PyObject_CallNoArgs (bpo-37194)
* PyThreadState_GetFrame (bpo-39947)
* PyThreadState_GetID (bpo-39947)
* PyThreadState_GetInterpreter (bpo-39947)

(cherry picked from commit fcc6935384b933fbe1a1ef659ed455a3b74c849a)

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39947] [C API] Make the PyThreadState structure opaque (move it to the internal C API)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 166286849048eccadecf02b242dbc4042b780944 by Victor Stinner in 
branch '3.9':
Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)
https://github.com/python/cpython/commit/166286849048eccadecf02b242dbc4042b780944


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37194] Move new vector private declarations to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 166286849048eccadecf02b242dbc4042b780944 by Victor Stinner in 
branch '3.9':
Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)
https://github.com/python/cpython/commit/166286849048eccadecf02b242dbc4042b780944


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 166286849048eccadecf02b242dbc4042b780944 by Victor Stinner in 
branch '3.9':
Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)
https://github.com/python/cpython/commit/166286849048eccadecf02b242dbc4042b780944


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37961] Tracemalloc traces do not include original stack trace length

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22670
pull_request: https://github.com/python/cpython/pull/23809

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37961] Tracemalloc traces do not include original stack trace length

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 051b9818671625d125dee8198e0d2af5ad4c85b8 by Daniel Hahler in 
branch 'master':
bpo-37961: Fix regression in tracemalloc.Traceback.__repr__ (GH-23805)
https://github.com/python/cpython/commit/051b9818671625d125dee8198e0d2af5ad4c85b8


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42663] zoneinfo does not support full range of allowed transition hours in fallback string

[Paul Ganssle]

New submission from Paul Ganssle :

TZif files consist of a list of transitions followed by a POSIX TZ var-style 
string of a form like "AAA3BBB,M3.2.0/01:30,M11.1.0/02:15:45", which decodes to 
"AAA (UTC-3) is the standard time and BBB (UTC-2) is the DST time, DST applies 
starting at 02:15:45 local time on the 1st Sunday in November and ending at 
1:30:00 local time on the 2nd Sunday in March". After the last listed 
transition, the rule specified by the TZ variable applies.

POSIX says that the "hours" part of the transition rule must be in the range 
±24, but as mentioned in a TODO comment in _zoneinfo.c, RFC 8536 §3.3.1 
specifies that the hours part of transition times may range from -167 to 167 
(see: 
https://github.com/python/cpython/blob/master/Modules/_zoneinfo.c#L1844-L1847 ).

Currently, zoneinfo does not support the full range of possible transitions, 
and a TZif file with a 3-digit transition hour would likely fail to parse. This 
isn't a terribly high priority at the moment, but if the tz project ever 
releases a TZif file with one of these TZ strings on it, it will all of a 
sudden become very critical to fix it, so we should probably try to get it 
fixed before Python 3.9 is EOL, so that all versions of Python with `zoneinfo` 
can handle this properly.

--
components: Library (Lib)
messages: 383206
nosy: p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: zoneinfo does not support full range of allowed transition hours in 
fallback string
type: behavior
versions: Python 3.10, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42662] Propose: Data model explict about __annotations__ key ordering.

[Paul Bryan]

Paul Bryan  added the comment:

Retracting.

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42662] Propose: Data model explict about __annotations__ key ordering.

[Paul Bryan]

Change by Paul Bryan :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42662] Propose: Data model explict about __annotations__ key ordering.

[Paul Bryan]

New submission from Paul Bryan :

Currently the data model documentation does not specify the order of keys in 
__annotations__ dictionary. It is currently in the order that arguments or 
attributes are declared. I propose to make this explicit.

Rationale: Having order explicitly specified in the documentation makes it a 
documented feature that code can depend on. Current code cannot safely rely on 
this behavior.

--
assignee: docs@python
components: Documentation
messages: 383204
nosy: docs@python, pbryan
priority: normal
severity: normal
status: open
title: Propose: Data model explict about __annotations__ key ordering.
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Paul Ganssle]

Paul Ganssle  added the comment:

> Adding a static assertion about the signedness of uint8_t looks meaningless 
> to me.

My proposal is to add a static assertion that `day` is an unsigned type. In the 
code it would look something like it does in the backports.zoneinfo code 
(https://github.com/pganssle/zoneinfo/blob/07ec80ad5dc7e7e4b4f861ddbb61a9b71e9f27c7/lib/zoneinfo_module.c#L1247-L1255):


```
// The actual bounds of day are (day >= 0 && day <= 6), but since day is an
// unsigned variable, day >= 0 is always true. To ensure that a bug is not
// introduced in the event that someone changes day to a signed type, we
// will assert that it is an unsigned type.
Py_ASSERT_VAR_UNSIGNED(day);
if (day > 6) {
PyErr_Format(PyExc_ValueError, "Day must be in [0, 6]");
return -1;
}
```

> I propose to change types of function parameters and local variables. In any 
> case the constructor checks the range of parameters, so there is no problem 
> with packing them into compact structure.

> This will help to avoid errors of implicit conversion between different 
> integer types. Also it can help to avoid code duplication in parsing integers 
> of different size and signedness.

This is not entirely unreasonable in my opinion, though in this case everything 
is determined by the POSIX standard and an RFC, so it is unlikely that we'll 
ever see anything outside of 8 bit integers for these things. If you'd like to 
refactor the parsing code to use signed integers unconditionally and have them 
converted as part of the constructor that seems reasonable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I propose to change types of function parameters and local variables. In any 
case the constructor checks the range of parameters, so there is no problem 
with packing them into compact structure.

This will help to avoid errors of implicit conversion between different integer 
types. Also it can help to avoid code duplication in parsing integers of 
different size and signedness.

Adding a static assertion about the signedness of uint8_t looks meaningless to 
me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42661] Hashlib Bug

[Zachary Ware]

Zachary Ware  added the comment:

`hashlib` is part of the standard library and thus does not need to be (and 
should not be :)) installed via pip.

--
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Paul Ganssle]

Paul Ganssle  added the comment:

There are at least two issues with this:

1. This is a constructor for a struct, and the struct would really 
unnecessarily balloon in size if we switched everything over to be 32-bit 
integers (which I think is your suggestion?). This is not a major concern 
because in typical operation there are not likely to be more than 500 of these 
structs in existence at any one time (due to the cache), but it's still a minor 
annoyance.

I would guess that accepting `int` in the constructor function and converting 
it to uint8_t as part of building the struct would be maybe neutral to 
negative, since it involves casting a large signed type to a small unsigned 
one. This could cause more problems with overflow, not less.

2. In the current implementation `day` is unsigned by its nature — it 
represents a value indexed at 0 for which negative indices have no meaning. If 
we leave `day` as a uint8_t, then that tells the compiler at least something 
about the valid range of the value. By turning `day` (and presumably the other 
elements of this struct) into a less-suitable type, we're depriving ourselves 
of possibly *useful* compiler warnings.

Barring a solution where we have a simple and robust way to suppress warnings, 
I think the next-best solution is to add a static assertion about the 
signedness of the type for this particular case. I'd be happy to write it in a 
relatively general way so that it can be re-used elsewhere in CPython for the 
same purpose.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[miss-islington]

miss-islington  added the comment:


New changeset dd262ef46d2e2fff4c413cfa5faa9e72cd36220e by Miss Islington (bot) 
in branch '3.8':
bpo-38323: Add guard clauses in MultiLoopChildWatcher. (GH-22756)
https://github.com/python/cpython/commit/dd262ef46d2e2fff4c413cfa5faa9e72cd36220e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42661] Hashlib Bug

[Samit Mohnot]

New submission from Samit Mohnot :

Complete output (6 lines):
Traceback (most recent call last):
  File "", line 1, in 
  File 
"C:\Users\Username\AppData\Local\Temp\pip-install-uyjqlzx9\hashlib_973e0ee3f102447498d1d4dca94b7942\setup.py",
 line 68
print "unknown OS, please update setup.py"
  ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean 
print("unknown OS, please update setup.py")?

ERROR: Command errored out with exit status 1: python setup.py egg_info Check 
the logs for full command output.

--
components: Library (Lib)
messages: 383198
nosy: samit.mohnot.018
priority: normal
severity: normal
status: open
title: Hashlib Bug
type: compile error
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[miss-islington]

miss-islington  added the comment:


New changeset bf0eed3e60acc7e4969a4fae940bc615fa924c30 by Miss Islington (bot) 
in branch '3.9':
bpo-38323: Add guard clauses in MultiLoopChildWatcher. (GH-22756)
https://github.com/python/cpython/commit/bf0eed3e60acc7e4969a4fae940bc615fa924c30


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

[miss-islington]

miss-islington  added the comment:


New changeset 9d409d6b474c188feca6213b9601e06f97715b72 by Miss Islington (bot) 
in branch '3.9':
bpo-39101: Fixes BaseException hang in IsolatedAsyncioTestCase. (GH-22654)
https://github.com/python/cpython/commit/9d409d6b474c188feca6213b9601e06f97715b72


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39101] IsolatedAsyncioTestCase freezes when exception is raised

[miss-islington]

miss-islington  added the comment:


New changeset d549d0b5575b390431b7b26999151f79f74d4516 by Miss Islington (bot) 
in branch '3.8':
bpo-39101: Fixes BaseException hang in IsolatedAsyncioTestCase. (GH-22654)
https://github.com/python/cpython/commit/d549d0b5575b390431b7b26999151f79f74d4516


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +22666
pull_request: https://github.com/python/cpython/pull/23806

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[Andrew Svetlov]

Andrew Svetlov  added the comment:


New changeset 66d3b589c44fcbcf9afe1e442d9beac3bd8bcd34 by Chris Jerdonek in 
branch 'master':
bpo-38323: Add guard clauses in MultiLoopChildWatcher. (#22756)
https://github.com/python/cpython/commit/66d3b589c44fcbcf9afe1e442d9beac3bd8bcd34


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38323] asyncio: MultiLoopWatcher has a race condition (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)

[miss-islington]

Change by miss-islington :


--
pull_requests: +22667
pull_request: https://github.com/python/cpython/pull/23807

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39041] Support GitHub Actions in CI

[Daniel Hahler]

Daniel Hahler  added the comment:

Is it planned to enable coverage uploads for PRs?
This would really help with seeing if code (to be merged) is covered etc.

--
nosy: +blueyed2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I propose to change the type of day to int. It will remove any objections 
againsy the range check and make the code less error-prone for integer overflow 
and sign loss.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41354] filecmp.cmp documentation does not match actual code

[Scott]

Scott  added the comment:

I suggest changing the documentation rather than the code.  The mix up is in 
the wording.

Documentation below
"If shallow is true, files with identical os.stat() signatures are taken to be 
equal. Otherwise, the contents of the files are compared."

The "Otherwise" appears to be referencing the "If shallow is true" cause, when 
it should be referring to the equality of the _sig()s.

Proposed Change 
"If shallow is true, files with identical os.stat() signatures are taken to be 
equal. If they are not equal, the contents of the files are compared."

--
nosy: +FreeSandwiches

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1571878] Improvements to socket module exceptions

[Irit Katriel]

Irit Katriel  added the comment:

This was indeed done by now - all these exception types now extend OSErrors, 
the hierarchy is very close to the one suggested here (with the exception of 
the AddressError superclass, which I don't think is that useful to have), and 
they have an errno field (derived from OSError).

--
nosy: +iritkatriel
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42556] unittest.mock.patch() cannot properly mock methods

[Mario Corchero]

Mario Corchero  added the comment:

Right, I believe this is indeed broken.

This code:
```
class A:
def m(self, a=None): pass

from unittest import mock
with mock.patch.object(A, "m", autospec=True):
A.m.side_effect = print
A().m(1)
```

prints: <__main__.A object at 0x7f69cc7dc6a0> 1

Whilst the same code without autospec:
```
class A:
def m(self, a=None): pass

from unittest import mock
with mock.patch.object(A, "m"):
A.m.side_effect = print
A().m(1)
```

prints: 1

This is a rather tricky issue though, as changing the behaviour to pass self 
would break too many people (even if it would probably the be "right" fix).

You can indeed use autospec or just write a descriptor that does the proper 
bound method logic:

```
class A:
def m(self, a=None): pass

def descriptor(self, obj, objtype=None):
self._self = obj
def _(*args):
return self(obj, *args)
return _

from unittest import mock
with mock.patch.object(A, "m"):
A.m.side_effect = print
A.m.__get__ = descriptor
A().m(1)
```

When patching a method at the class level, today Mock is basically hiding 
"self" when used without a spec. We should decide whether:
- that is OK and we want to "fix" autospec to do the same (remove self)
- Leave things as they are, even if not perfect
- Pass self, breaking most assertions across the world (sounds like a bad idea 
initially)
- Create some opt-in parameter or a custom thing like PropertyMock to pass self 
(MethodMock?).

TBH, I don't have a good answer :/. I'm subscribing other more insightful 
people to the issue, maybe this is the way it is intended to work :).

--
nosy: +cjw296, mariocj89, michael.foord, xtreak

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Paul Ganssle]

Paul Ganssle  added the comment:

> Just my two cents, this isn't just "some compilers". Everything from gcc, 
> msvc, C# to the rust compiler complain about this sort of code. As they 
> should, this is effectively dead code.

They complain because most of the time it's a sign that people were intending 
to use a signed integer, and it's an indicator that they may be susceptible to 
integer overflow.

In this case, it was a deliberate choice to include the extra check knowing 
it's dead code, because it is essentially a machine-checked documentation of 
the bounds of that particular variable.


> I think the more pragmatic way to enforce and document this assumption would 
> be to have a unit test that actually checks that the constructor fails with 
> "negative" days. It'll continue to fail right now as its interpretation as an 
> unsigned int will be large and it will start failing if someone changes this 
> to a signed type.

This would be helpful, but it's not an either-or situation. This particular 
thing would be tricky to write a targeted unit test for, because it's a very 
deep implementation detail. Such a unit test would also be quite physically 
separated from the code in question, whereas if we left the code as-is, we'd 
never see this type of bug, and if we added a static assertion we'd be told at 
compile time exactly what is wrong.

The biggest problem here is the fact that we cannot disable compiler warnings 
when complying with them makes the code less readable and/or less robust. This 
makes compiler warnings less useful, since it changes the calculus around 
whether or not it's worth it to introduce a new compiler warning.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Ammar Askar]

Ammar Askar  added the comment:

> Some compilers complain about checking `day < 0`, because `day` is an 
> unsigned type

Just my two cents, this isn't just "some compilers". Everything from gcc, msvc, 
C# to the rust compiler complain about this sort of code. As they should, this 
is effectively dead code.

I think the more pragmatic way to enforce and document this assumption would be 
to have a unit test that actually checks that the constructor fails with 
"negative" days. It'll continue to fail right now as its interpretation as an 
unsigned int will be large and it will start failing if someone changes this to 
a signed type.

--
nosy: +ammar2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Paul Ganssle]

Paul Ganssle  added the comment:

As I mentioned, it's a style issue. Yes this did not introduce any 
user-observable bugs, nor should it have changed the machine code emitted by 
the assembly on any competent compiler.

The issue is that I had deliberately chosen to do a "redundant" check to 
improve the readability and to be robust against someone saying, "Why is this a 
unit8_t instead of an int? I don't think it makes anything faster..." or some 
other justification for changing all the uint8_t fields to ints.

Previous to this, we had something where the compiler would fix any bugs caused 
by that by itself by emitting an additional bounds check. In my proposed fix to 
the compiler warnings, there was a static assertion where the machine would 
alert us if the situation changed. The problem is that we now have a 
non-machine-checked comment for something that would be difficult to issue 
tests for.

Frankly, I think that even the worst case scenario here isn't that bad — TZif 
files malformed in a very specific way would be accepted as valid. As it's 
coded now, this would probably just lead to a crash later, or possibly some 
weird results in time zone math. Still, I think we need a solution to this 
problem because our blind adherence to an invalid compiler warning is leading 
us to write more fragile code, whic h is especially problematic in C, which is 
notoriously dangerous and problematic to write.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:

Paul created a follow-up issue: bpo-42660.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 7492b55ea0ca993c353b6373341b92e40faa9c4d by Miss Islington (bot) 
in branch '3.9':
bpo-40686: Fix compiler warnings on _zoneinfo.c (GH-23614) (GH-23804)
https://github.com/python/cpython/commit/7492b55ea0ca993c353b6373341b92e40faa9c4d


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42659] Objects of uname_result Class Cannot be Successfully Pickled

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

See also issue42189.

--
components: +Library (Lib)
nosy: +jaraco, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I do not think there is any problem *now*. The type of day is uint8_t, it 
cannot be negative.

BTW, why is it uint8_t? Would not be easier to use type int by default? I doubt 
that it saves memory or makes the code faster.

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23915] [doc] traceback set with BaseException.with_traceback() pushed back on raise

[Julien Palard]

Change by Julien Palard :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23915] [doc] traceback set with BaseException.with_traceback() pushed back on raise

[Julien Palard]

Julien Palard  added the comment:


New changeset c590c2338e5a36cf3ce5b55e6d366a0675ed1db5 by Irit Katriel in 
branch 'master':
bpo-23915: update and elucidate documentation of with_traceback (GH-23680)
https://github.com/python/cpython/commit/c590c2338e5a36cf3ce5b55e6d366a0675ed1db5


--
nosy: +mdk

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37961] Tracemalloc traces do not include original stack trace length

[daniel hahler]

Change by daniel hahler :


--
nosy: +blueyed
nosy_count: 2.0 -> 3.0
pull_requests: +22665
pull_request: https://github.com/python/cpython/pull/23805

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new

[Paul Ganssle]

New submission from Paul Ganssle :

This is a code style issue — in https://github.com/python/cpython/pull/23614, a 
regression was deliberately introduced to satisfy an overzealous compiler. The 
`day` variable has logical bounds `0 <= day <= 6`. In the original code, both 
sides of this boundary condition were explicitly checked (since this logically 
documents the bounds of the variable).

Some compilers complain about checking `day < 0`, because `day` is an unsigned 
type. It is not an immutable fact that `day` will always be an unsigned type, 
and implicitly relying on this fact makes the code both less readable and more 
fragile. This was changed over my objections and despite the fact that I had a 
less fragile solution available that also satisfied the overzealous compiler.

In the short term, my preferred solution would be to add in a static assertion 
that `day` is an unsigned type — this does not have to work on every platform, 
it simply needs to serve as a notification to make the code less fragile and to 
document our assumptions to both readers and the compiler.

In the long term, I think we need a way to solve the problem that it is 
apparently not possible to disable any compiler warnings even if they don't 
apply to the situation!

--
components: Library (Lib)
messages: 383180
nosy: p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: _zoneinfo.c incorrectly checks bounds of `day` variable in 
calenderrule_new
type: behavior
versions: Python 3.10, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:

Fixing these compiler warnings helps PR 18532 "[workflow] Use MSVC problem 
matcher for Windows action build".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:

The 3 compiler warnings are now fixed in master, and a 3.9 backport will land 
as soon as the CI tests pass. Thanks everyone who helped to fix these warnings.

I know that the solution is not perfect, but we have to deal with C language 
limitations.

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22664
pull_request: https://github.com/python/cpython/pull/23804

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:


New changeset aefb69b23f056c61e82ad228d950f348de090c70 by Victor Stinner in 
branch 'master':
bpo-40686: Fix compiler warnings on _zoneinfo.c (GH-23614)
https://github.com/python/cpython/commit/aefb69b23f056c61e82ad228d950f348de090c70


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42529] CPython DLL initialization routine failed from PYC cache file

[Karl Nelson]

Karl Nelson  added the comment:

I am fairly sure this is a Python "bug" in the sense that there was some change 
in undocumented change in requirements and the distutils pattern for building a 
module no longer reflects that requirement.   That said very likely JPype is 
the only module to be affected and thus I will have to manually adjust to 
account for the new requirement.

Unfortunately as far as developers, I am it so fixing it (with your assistance) 
is going to have to fall on me.  So lets do a run down of how this all working 
so you can point me where to look.

1) JPype gets built as an ordinary setup.py CPython module.  So it is possibly 
a bug in the build pattern of the customizers in JPype that was exposed by 
Python 3.9.   I am just going to cut and paste so that it is easy to follow 
along.

jpype/setup.py
```
...
from setuptools import Extension
...
import setupext
...
jpypeLib = Extension(name='_jpype', **setupext.platform.Platform(
include_dirs=[Path('native', 'common', 'include'),
  Path('native', 'python', 'include'),
  Path('native', 'embedded', 'include')],
sources=[Path('native', 'common', '*.cpp'),
 Path('native', 'python', '*.cpp'),
 Path('native', 'embedded', '*.cpp')], platform=platform,
))
```

We have two sets of customization in setup.py.  Both are included from a module 
called jpype/setupext/

The key one is the jpype/setupext/platform.py which defines the compiler flags. 
 There are two sections of interest...

jpype/setupext/platform.py contains these modifications for win32.   
(So there is the Advapi32, not sure why it appears there because this section 
is all before my time as this was started in 2001 and I joined in 2018)
```
static = True
if platform == 'win32':
distutils.log.info("Add windows settings")
platform_specific['libraries'] = ['Advapi32']
platform_specific['define_macros'] = [('WIN32', 1)]
if sys.version > '3':
platform_specific['extra_compile_args'] = [
'/Zi', '/EHsc', '/std:c++14']
else:
platform_specific['extra_compile_args'] = ['/Zi', '/EHsc']
platform_specific['extra_link_args'] = ['/DEBUG']
jni_md_platform = 'win32'
```

The second section is currently commented out.  Though it is relevant because 
JPype is exotic in one way.  It is a module which is loaded in three ways.   
When imported from Python it is an ordinary library (1) which will later pull 
in Java which will then load library a second time (2) to bind Java native 
methods.   It can also be used to launch Python if Java starts the session (3). 
  In that case, it needs libpython.dll to be bound to module so that the Java 
equivalent to LoadLibrary can work.  When it does Java first manually loads 
libpython.dll then loads the module and calls the hook to get Python started. 
```
# This code is used to include python library in the build when starting Python 
from
# within Java.  It will be used in the future, but is not currently required.
#if static and sysconfig.get_config_var('BLDLIBRARY') is not None:
#
platform_specific['extra_link_args'].append(sysconfig.get_config_var('BLDLIBRARY'))
```

The actual buildext has a few minor patches so that Java libraries can run 
through the normal process.  But nothing seems like a good candidate

We have one section tweeking some of the build options.
```
def initialize_options(self, *args):
"""omit -Wstrict-prototypes from CFLAGS since its only valid for C 
code."""
self.android = False
self.makefile = False
self.jar = False
import distutils.sysconfig
cfg_vars = distutils.sysconfig.get_config_vars()
replacement = {
'-Wstrict-prototypes': '',
'-Wimplicit-function-declaration': '',
}
tracing = self.distribution.enable_tracing

# Arguments to remove so we set debugging and optimization level
remove_args = ['-O0', '-O1', '-O2', '-O3', '-g']

for k, v in cfg_vars.items():
if not isinstance(v, str):
continue
if not k == "OPT" and not "FLAGS" in k:
continue

args = v.split()
for r in remove_args:
args = list(filter((r).__ne__, args))

cfg_vars[k] = " ".join(args)
super().initialize_options()
```

Then later we interrupt the build process for Java.
```
def build_extension(self, ext):
if ext.language == "java":
return self.build_java_ext(ext)
if self.jar:
return
print("Call build ext")
return super().build_extension(ext)
```

2) Next we have the module start.  I am guessing this is not the source of the 
error because adding a printf shows we never got to this point.

jpype/native/pyjp_module.cpp
```
PyMODINIT_FUNC PyInit__jpype()
{
JP_PY_TRY("PyInit__jpype");

[issue40686] Compiler warnings in _zoneinfo.c on Windows build in 64-bit

[STINNER Victor]

STINNER Victor  added the comment:

The problem can be simplified to this x.c file:
---
static int invalid_day(unsigned int day)
{
return (day < 0 || day > 6);
}

int main()
{
invalid_day(3);
return 0;
}
---

GCC emits the warning:

$ gcc x.c -o x -O3 -Wall -Wextra
x.c: In function 'invalid_day':
x.c:3:17: warning: comparison of unsigned expression in '< 0' is always false 
[-Wtype-limits]
3 | return (day < 0 || day > 6);
  | ^

There are different options to avoid the warning:


(A) Remove "day < 0" test

Easiest option, portable, simple: my PR 23614.


(B) Disable compiler warnings on the test

Solution currently implemented with pragma + PR 20619 to fix pragmas.


(C) Cast the 'day' variable to a signed type

I understand that Paul wants the code to be as generic as possible, and not 
depending on the "day" parameter type. For example, casting to "int8_t" may 
introduce a risk of integer overflow if day type is larger than 8 bits. Not my 
favorite option.


(D) Make "day < 0" conditional depending if day type is signed or not
(E) Check that day type is unsigned to ensure indirectly that "day >= 0"

Checking if *a type* is signed or not is easy using the C preprocessor:

#define _Py_IS_TYPE_UNSIGNED(type) (((type)-1) > (type)0) 

The problem is that there is no standard function to get a variable type. GCC 
and clang provide the __typeof__(var) extension, C++ provides decltype(var) 
(but CPython code base cannot be built with a C++ compiler if I recall 
correctly).

Paul's PR 20624 introduces Py_ASSERT_VAR_UNSIGNED(var) macro which fails during 
compilation if the variable is unsigned, or does nothing if the compiler 
doesn't provide a way to get a variable type (ex: MSC on Windows).


--


Most answers about "comparison of unsigned expression always false" question on 
the Internet are (A): remove the check which emits the warning.

My worry is also that outside _zoneinfo.c, they are tons of functions which 
rely on the fact that an unsigned type cannot be negativ. I don't want to start 
adding Py_ASSERT_VAR_UNSIGNED(). For me, it's part of the C language and there 
is no need to be explicit about it. If a developer changes a variable type, 
they have to check the type bounds and check of the variable is used.

I would prefer to be consistent and never check for "< 0" if the type is 
unsigned, nor ensure with an assertion that the type is unsigned.

Paul is in disagreement with that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42659] Objects of uname_result Class Cannot be Successfully Pickled

[CrocoDuck]

New submission from CrocoDuck :

See the code example below.

```python
import platform
import pickle

pack = {
'uname_result': platform.uname()
}

with open('test.pickle', 'wb') as f:
pickle.dump(pack, f, protocol=pickle.HIGHEST_PROTOCOL)

with open('test.pickle', 'rb') as f:
data = pickle.load(f)

```

It works smoothly on Python 3.8.5. However, on Python 3.9.0, the last line 
produces this error:

```
Traceback (most recent call last):
  File "/Users/crocoduck/pickle/3.9.0/make_pickle.py", line 12, in 
data = pickle.load(f)
TypeError: () takes 6 positional arguments but 7 were given
```

The files produced by the code snipped above are attached for reference.

This was observed in macOS Catalina 10.15.7.

--
files: pickles.zip
messages: 383174
nosy: CrocoDuck
priority: normal
severity: normal
status: open
title: Objects of uname_result Class Cannot be Successfully Pickled
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49688/pickles.zip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

[Mark Shannon]

Change by Mark Shannon :


--
pull_requests: +22663
pull_request: https://github.com/python/cpython/pull/23803

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42615] Redundant jump instructions due to deleted unreachable bytecode blocks

[Om G]

Change by Om G :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42629] PyObject_Call not behaving as documented

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Pingback from #42033. Proper fix for that issue likely involves moving the work 
for copying kwargs into PyObject_Call, which would fix this bug by side-effect.

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42033] Seemingly unnecessary complexification of foo(**kw)

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Even if making a copy is necessary when the underlying function receives the 
dict "raw", preemptively performing the copy (before knowing if the function 
being called is a Vectorcall function) means that when it's a Vectorcall 
function (e.g. all user-defined functions, right?), instead of just copying 
from the original dict to the unpacked stack for vectorcall, it makes an 
intermediate copy, then copies from that copy to the unpacked stack later on; 
the copy is otherwise completely unused.

The extra bytecode isn't even defending against "dict-like" kwargs, because 
CALL_FUNCTION_EX itself already copies to a true dict for anything that's not 
an exact dict (that defense shouldn't even be there if the bytecode compiler is 
already guaranteeing a true dict).

Seems like, if preventing the caller's dict from being passed directly to the 
underlying function is necessary and intended, it should be done in 
PyObject_Call (which can avoid the copy entirely when call a Vectorcall 
function and when the reference count on the dict is 1), not at the bytecode 
interpreter layer. As is, PyObject_Call is already violating the documented 
behavior by *not* matching the behavior of callable(*args, **kwargs) (see 
#42629), so moving it to PyObject_Call would fix that problem and improve 
performance passing a single kwargs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42238] Deprecate suspicious.py?

[Julien Palard]

Julien Palard  added the comment:

I created https://github.com/python/cpython/pull/23802 with a port of the 
"wrong backtick detector" (at least, one aspect from it) from suspicious to 
rstlint.

I dropped the suspicious check three weeks ago, and found a single committed 
issue since then, which was fixable (and is fixed) in rstlint, so I'll continue 
this experience and see where it goes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42238] Deprecate suspicious.py?

[Julien Palard]

Change by Julien Palard :


--
pull_requests: +22662
pull_request: https://github.com/python/cpython/pull/23802

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42415] python3.lib in Python3.9.0 Windows distribution does not contain PyObject_CallNoArgs symbol

[STINNER Victor]

STINNER Victor  added the comment:

commit fcc6935384b933fbe1a1ef659ed455a3b74c849a
Author: Victor Stinner 
Date:   Wed Dec 16 15:08:23 2020 +0100

Add symbols of the stable ABI to python3dll.c (GH-23598)

Add the following symbols to python3dll.c:

* PyFrame_GetCode (bpo-40421)
* PyFrame_GetLineNumber (bpo-40421)
* PyModule_AddObjectRef (bpo-1635741)
* PyObject_CallNoArgs (bpo-37194)
* PyThreadState_GetFrame (bpo-39947)
* PyThreadState_GetID (bpo-39947)
* PyThreadState_GetInterpreter (bpo-39947)

I backported the change manually to 3.9: PR 23801.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +22659
pull_request: https://github.com/python/cpython/pull/23801

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42415] python3.lib in Python3.9.0 Windows distribution does not contain PyObject_CallNoArgs symbol

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner
nosy_count: 7.0 -> 8.0
pull_requests: +22658
pull_request: https://github.com/python/cpython/pull/23801

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39947] [C API] Make the PyThreadState structure opaque (move it to the internal C API)

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +22661
pull_request: https://github.com/python/cpython/pull/23801

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37194] Move new vector private declarations to the internal C API

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +22660
pull_request: https://github.com/python/cpython/pull/23801

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37194] Move new vector private declarations to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:


New changeset fcc6935384b933fbe1a1ef659ed455a3b74c849a by Victor Stinner in 
branch 'master':
Add symbols of the stable ABI to python3dll.c (GH-23598)
https://github.com/python/cpython/commit/fcc6935384b933fbe1a1ef659ed455a3b74c849a


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40421] [C API] Add getter functions for PyFrameObject and maybe move PyFrameObject to the internal C API

[STINNER Victor]

STINNER Victor  added the comment:


New changeset fcc6935384b933fbe1a1ef659ed455a3b74c849a by Victor Stinner in 
branch 'master':
Add symbols of the stable ABI to python3dll.c (GH-23598)
https://github.com/python/cpython/commit/fcc6935384b933fbe1a1ef659ed455a3b74c849a


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39947] [C API] Make the PyThreadState structure opaque (move it to the internal C API)

[STINNER Victor]

STINNER Victor  added the comment:


New changeset fcc6935384b933fbe1a1ef659ed455a3b74c849a by Victor Stinner in 
branch 'master':
Add symbols of the stable ABI to python3dll.c (GH-23598)
https://github.com/python/cpython/commit/fcc6935384b933fbe1a1ef659ed455a3b74c849a


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[STINNER Victor]

STINNER Victor  added the comment:


New changeset fcc6935384b933fbe1a1ef659ed455a3b74c849a by Victor Stinner in 
branch 'master':
Add symbols of the stable ABI to python3dll.c (GH-23598)
https://github.com/python/cpython/commit/fcc6935384b933fbe1a1ef659ed455a3b74c849a


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42645] break/continue or return in finally block occurs twice in trace.

[Mark Shannon]

Mark Shannon  added the comment:


New changeset 5274b682bc93a04da8a69742528ac7f64633a96e by Mark Shannon in 
branch 'master':
bpo-42645: Make sure that return/break/continue are only traced once when 
exiting via a finally block. (GH-23780)
https://github.com/python/cpython/commit/5274b682bc93a04da8a69742528ac7f64633a96e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42654] Add folder for python customizations: __sitecustomize__

[Mario Corchero]

Mario Corchero  added the comment:

Thread open in Python ideas: 
https://discuss.python.org/t/add-folder-for-python-customizations-sitecustomize/6190/5

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42658] os.path.normcase() is inconsistent with Windows file system

[sogom]

New submission from sogom :

On Windows file system, U+03A9 (Greek capital letter Omega) and U+2126 (Ohm 
sign) are distinguished. In fact, two distinct files "\u03A9.txt" and 
"\u2126.txt" can exist side by side in the same folder. But os.path.normcase() 
transforms both U+03A9 and U+2126 to U+03C9 (Greek small letter omega).

MSDN reads they use CompareStringOrdinal() to compare NTFS file names: 
https://docs.microsoft.com/en-us/windows/win32/intl/handling-sorting-in-your-applications#sort-strings-ordinally
 . This document also says "the function maps case using the operating system 
*uppercasing* table." But I made an experiment and found that at least in the 
Basic Multilingual Plane, "lowercase two strings by means of LCMapStringEx() 
and then wcscmp the two" always gives the same result as "compare the two 
strings with CompareStringOrdinal()". Though this fact is not explicitly 
mentioned in MSDN 
https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-lcmapstringex
 , the description of LCMAP_LINGUISTIC_CASING in this page implies that casing 
rules conform to file system's unless LCMAP_LINGUISTIC_CASING is used.

Therefore, I believe that os.path.normcase() should probably call 
LCMapStringEx(), with the first argument LOCALE_NAME_INVARIANT and the second 
argument LCMAP_LOWERCASE.

--
components: Windows
messages: 383163
nosy: paul.moore, sogom, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.normcase() is inconsistent with Windows file system
type: behavior
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I think I am closing the PR as it seems that the gains are not good enough (and 
there is quite a lot of noise by comparing the benchmarks together).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40821] os.getlogin() not working

[Christian Heimes]

Christian Heimes  added the comment:

errno 6 is ENXIO. According to 
https://www.man7.org/linux/man-pages/man3/getlogin.3.html the error code means 
"The calling process has no controlling terminal.".

os.getlogin() returns the name of the user logged in on the controlling 
terminal of the process. Typically processes in user session (tty, X session) 
have a controlling terminal. Processes spawned by a service manager like init, 
systemd, or upstart usually do not have a controlling terminal. You have to get 
the user information by other means. Our documentation for os.getlogin() 
recommends getpass.getuser().

--
resolution:  -> not a bug
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

OK, I have repeated the benchmarks after rebasing and this is what I get:

venv ❯ python -m pyperf compare_to 
json/2020-12-16_11-20-master-8203c73f3bb1.json.gz 
json/2020-12-16_11-22-load_method-21b1566125b3.json.gz -G --min-speed=1
Slower (13):
- regex_v8: 30.5 ms +- 0.1 ms -> 32.8 ms +- 0.2 ms: 1.08x slower (+8%)
- pidigits: 253 ms +- 0 ms -> 264 ms +- 0 ms: 1.05x slower (+5%)
- richards: 84.1 ms +- 1.1 ms -> 87.4 ms +- 1.4 ms: 1.04x slower (+4%)
- fannkuch: 573 ms +- 2 ms -> 589 ms +- 14 ms: 1.03x slower (+3%)
- regex_effbot: 3.87 ms +- 0.03 ms -> 3.98 ms +- 0.05 ms: 1.03x slower (+3%)
- scimark_sor: 223 ms +- 4 ms -> 227 ms +- 2 ms: 1.02x slower (+2%)
- pathlib: 20.9 ms +- 0.2 ms -> 21.3 ms +- 0.3 ms: 1.02x slower (+2%)
- regex_compile: 209 ms +- 1 ms -> 212 ms +- 3 ms: 1.01x slower (+1%)
- xml_etree_process: 93.7 ms +- 0.7 ms -> 94.9 ms +- 1.1 ms: 1.01x slower (+1%)
- nqueens: 122 ms +- 1 ms -> 123 ms +- 1 ms: 1.01x slower (+1%)
- regex_dna: 263 ms +- 1 ms -> 266 ms +- 1 ms: 1.01x slower (+1%)
- django_template: 56.1 ms +- 0.4 ms -> 56.7 ms +- 0.4 ms: 1.01x slower (+1%)
- raytrace: 566 ms +- 7 ms -> 572 ms +- 6 ms: 1.01x slower (+1%)

Faster (15):
- unpack_sequence: 80.4 ns +- 0.9 ns -> 70.8 ns +- 0.8 ns: 1.14x faster (-12%)
- scimark_sparse_mat_mult: 6.26 ms +- 0.02 ms -> 5.97 ms +- 0.06 ms: 1.05x 
faster (-5%)
- pickle_pure_python: 547 us +- 5 us -> 523 us +- 5 us: 1.05x faster (-4%)
- unpickle: 17.7 us +- 0.1 us -> 17.0 us +- 0.2 us: 1.04x faster (-4%)
- mako: 20.0 ms +- 0.1 ms -> 19.5 ms +- 0.1 ms: 1.02x faster (-2%)
- unpickle_pure_python: 361 us +- 4 us -> 353 us +- 4 us: 1.02x faster (-2%)
- logging_simple: 9.59 us +- 0.14 us -> 9.39 us +- 0.12 us: 1.02x faster (-2%)
- scimark_fft: 462 ms +- 4 ms -> 455 ms +- 4 ms: 1.02x faster (-2%)
- chameleon: 11.6 ms +- 0.2 ms -> 11.4 ms +- 0.1 ms: 1.02x faster (-2%)
- pickle: 13.0 us +- 0.1 us -> 12.8 us +- 0.1 us: 1.02x faster (-1%)
- telco: 8.30 ms +- 0.23 ms -> 8.18 ms +- 0.14 ms: 1.01x faster (-1%)
- go: 277 ms +- 2 ms -> 274 ms +- 2 ms: 1.01x faster (-1%)
- pickle_list: 5.30 us +- 0.07 us -> 5.23 us +- 0.06 us: 1.01x faster (-1%)
- logging_format: 10.3 us +- 0.1 us -> 10.2 us +- 0.1 us: 1.01x faster (-1%)
- meteor_contest: 136 ms +- 0 ms -> 134 ms +- 1 ms: 1.01x faster (-1%)

Benchmark hidden because not significant (32): 2to3, chaos, crypto_pyaes, 
deltablue, dulwich_log, float, genshi_text, genshi_xml, hexiom, json_dumps, 
json_loads, logging_silent, nbody, pickle_dict, pyflate, python_startup, 
python_startup_no_site, scimark_lu, scimark_monte_carlo, spectral_norm, 
sqlalchemy_declarative, sqlalchemy_imperative, sqlite_synth, sympy_expand, 
sympy_integrate, sympy_sum, sympy_str, tornado_http, unpickle_list, 
xml_etree_parse, xml_etree_iterparse, xml_etree_generate

--
Added file: https://bugs.python.org/file49687/result.zip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42246] Implement PEP 626 -- Precise line numbers for debugging

[Mark Shannon]

Mark Shannon  added the comment:

https://github.com/python/cpython/pull/23780 fixes the finally handling.
The if-break case was fixed by earlier changes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42529] CPython DLL initialization routine failed from PYC cache file

[Steve Dower]

Steve Dower  added the comment:

Sorry, I haven't had a chance to set up a test machine with all the 
requirements.

It's almost certainly something in jpype, to be clear. Most likely it loads a 
DLL that hasn't been loaded yet, but does it under conditions where it won't 
load. Nothing we build as part of CPython should do anything interesting on 
load, at least nothing we can change/fix. So jpype will probably need an update 
to import something manually.

The only thing I can think of that changed along these lines in 3.9.0 is that 
we no longer LoadLibrary("api-ms-win-core-path-l1-1-0.dll") at startup (because 
we can assume that it's present now). That shouldn't matter at all unless jpype 
is doing some really weird stuff, as it's a system library with no code. But 
maybe it'll give someone a hint who knows the module better?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42615] Redundant jump instructions due to deleted unreachable bytecode blocks

[Mark Shannon]

Mark Shannon  added the comment:


New changeset c71581c7a4192e6ba9a79eccc583aaadab300efa by Om G in branch 
'master':
bpo-42615: Delete redundant jump instructions that only bypass empty blocks 
(GH-23733)
https://github.com/python/cpython/commit/c71581c7a4192e6ba9a79eccc583aaadab300efa


--
nosy: +Mark.Shannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40821] os.getlogin() not working

[Philipp Gortan]

Change by Philipp Gortan :


--
nosy: +mephinet

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42591] Method Py_FrozenMain missing in libpython3.9

[Christian Bachmaier]

Christian Bachmaier  added the comment:

Vistor Stinner:
> If you can test it, I can backport the fix to stable branches.

Seems to work like a charm. Basically I used the same testing setup as 
previously on Dec 10th under Debian testing/bullseye without step 2, as master 
already contains your fix.

Victor, many thanks again, you are great!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 8203c73f3bb1f51614279b6e23af2ec587d1fa22 by Victor Stinner in 
branch 'master':
bpo-1635741: Refactor _threadmodule.c (GH-23793)
https://github.com/python/cpython/commit/8203c73f3bb1f51614279b6e23af2ec587d1fa22


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42591] Method Py_FrozenMain missing in libpython3.9

[STINNER Victor]

STINNER Victor  added the comment:

Christian Bachmaier:
> The symlink does the trick. So it may be easy for you to fix that, so it does 
> operate out of the box again.

I pushed a fix in bpo-42613. It would be great if you could test it.

See my manual test: https://bugs.python.org/issue42613#msg383153

If you can test it, I can backport the fix to stable branches.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42613] freeze.py doesn't support sys.platlibdir different than lib nor multiarch

[STINNER Victor]

STINNER Victor  added the comment:

I tested my fix with these commands:
---
./configure --with-platlibdir=lib64 --enable-shared --prefix /opt/py310 
CFLAGS="-O0"
make
make install
# move outside CPython source tree
cd

mkdir hello
cd hello
echo 'print("hello")' > hello.py

cp -R  ~/python/master/Tools/freeze/ .
LD_LIBRARY_PATH=/opt/py310/lib /opt/py310/bin/python3.10 freeze/freeze.py 
hello.py
---

Output:
---
$ LD_LIBRARY_PATH=/opt/py310/lib ./hello 
hello
---

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42115] Caching infrastructure for the evaluation loop: specialised opcodes

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Oh, I am quite confused about what's going on with pidigits and regex_v8. I 
will try to run the benchmarks again. Did you compare the current master 
against the PR? If that's the case we should rebase the PR it first to make 
sure we are comparing it correctly.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42613] freeze.py doesn't support sys.platlibdir different than lib nor multiarch

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42613] freeze.py doesn't support sys.platlibdir different than lib nor multiarch

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 1c653f17cb84d81df3a74ab0b42140d2bb68c5c4 by Victor Stinner in 
branch 'master':
bpo-42613: Fix freeze.py config directory (GH-23792)
https://github.com/python/cpython/commit/1c653f17cb84d81df3a74ab0b42140d2bb68c5c4


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40364] asyncio: replace _compute_returncode() with os.waitstatus_to_exitcode()

[STINNER Victor]

Change by STINNER Victor :


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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40364] asyncio: replace _compute_returncode() with os.waitstatus_to_exitcode()

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 99d28c56708bff1f442e1df5748adb2620542c61 by Victor Stinner in 
branch 'master':
bpo-40364: asyncio uses os.waitstatus_to_exitcode() (GH-23798)
https://github.com/python/cpython/commit/99d28c56708bff1f442e1df5748adb2620542c61


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com