Mailman 3 February 2020 - Python-Dev

Hang with parallel make
by e2lahav＠gmail.com Feb. 29, 2020

Feb. 29, 2020

Hello, I have successfully built Python 3.8.1 on QNX, but ran into a problem when using 'make -j4'. The build process invariably hangs with multiple single-threaded child processes stuck indefinitely waiting on semaphores. These semaphores will clearly never be posted to, as the processes are all single threaded and the semaphores are not shared with any other process. A backtrace shows that the the offending calls come from run_at_forkers(), which is not surprising. I consider a multi-… [View More]

5 12

Summary of Python tracker Issues
by Python tracker Feb. 28, 2020

Feb. 28, 2020

ACTIVITY SUMMARY (2020-02-21 - 2020-02-28) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7333 (+18) closed 44202 (+52) total 51535 (+70) Open issues with patches: 2882 Issues opened (53) ================== #17422: language reference should specify restrictions on class namesp https://bugs.python.org/issue17422 reopened by eric.snow #25960: … [View More]

1 0

Merging PRs without CLA signed
by Kyle Stanley Feb. 27, 2020

Feb. 27, 2020

In a recently opened typo fixing PR [1], an issue came up regarding the lack of a signed CLA, where the author specifically mentioned they did not want to sign it for privacy concerns. In the past, I've seen several PRs with similarly minimal [2] changes (such as typo fixes, grammar fixes, link fixes, etc) merged without having the CLA signed, so it was my assumption that this was acceptable. For a full list of merged PRs to CPython with a "CLA not signed" label, see the following: https://… [View More]github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Apr+state%3Ame… However, I was informed by Pablo Galindo that there are legal issues involved with merging *any* PRs without the CLA signed, including typo fixes. Personally, I have no strong opinion one way or the other, as I don't have an adequate understanding from a legal/licensing perspective. But, I think think there's definitely an issue with the lack of consistency regarding this policy. *To require a signed CLA for some minimal PRs but not others, solely based on who happens to be reviewing the PR, seems rather unfair to potential contributors.* From my perspective, the solution seems to be clearly defining a more explicit stance on this policy, and having it apply as universally as possible to *all* PRs made to CPython. For example, if the CLA should be required for all PRs, the policy might state something like this: "The author of any PR made to the CPython repository must have signed the CLA before their PR can be merged. Any PR opened by an author that has not signed the CLA can't be merged until it has been signed." OTOH, if it's okay for minimal PRs to not have a signed CLA: "The author of any PR made to the CPython repository must have signed the CLA before their PR can be merged, except for minimal PRs. Some examples of minimal PRs include: ..." Currently, the policy seems to be learning more towards the former based on the devguide [3], where it states "To accept your change we must have your formal approval for distributing your work under the PSF license. Therefore, you need to sign a contributor agreement which allows the Python Software Foundation to license your code for use with Python (you retain the copyright)". However, it seems apparent to me that either this policy isn't explicit enough, has a lack of visibility, or simply isn't followed consistently. What might be a viable solution to this problem? --- [1] - https://github.com/python/cpython/pull/18603 [2] - The term "minimal" can be interchanged with "trivial" for the most part in the above context, but I tend to prefer the former. IMO, it comes across as more respectful to the efforts made by the author, as even the smallest of PRs can require substantial efforts from first-time contributors that are entirely unfamiliar with the workflow; regardless of how small the change is. [3] - https://devguide.python.org/pullrequest/#licensing Regards, Kyle Stanley [View Less]

11 16

Accepting PEP 584: Add Union Operators To dict
by Guido van Rossum Feb. 27, 2020

Feb. 27, 2020

Now that the last bits of discussion about PEP 584 have been settled (we will *not* be calling the `copy` or `update` methods) I am accepting this PEP. Congratulations Steven and Brandt! Thanks to everyone else who gave their opinion. Formally, I will just send my recommendation to accept the PEP to the Steering Council -- they will then let us know whether they agree, and once that's done we can update the PEP with the "Accepted" status and land the implementation (https://github.com/python/… [View More]

10 27

Unpacking native bools in the struct module: Is Python relying on undefined behavior?
by Charalampos Stratakis Feb. 27, 2020

Feb. 27, 2020

Hello folks, I recently observed a failure on the s390x fedora rawhide buildbot, on the clang builds, when clang got updated to version 10: https://bugs.python.org/issue39689 The call: struct.unpack('>?', b'\xf0') means to unpack a "native bool", i.e. native size and alignment. Internally, this does: static PyObject * nu_bool(const char *p, const formatdef *f) { _Bool x; memcpy((char *)&x, p, sizeof x); return PyBool_FromLong(x != 0); } … [View More]

3 3

3.7.7 schedule accelerated, cutoff now 2020-03-02
by Ned Deily Feb. 26, 2020

Feb. 26, 2020

https://discuss.python.org/t/3-7-7-schedule-accelerated-cutoff-now-2020-03-… -- Ned Deily nad(a)python.org -- []

1 0

Python 3.8.2 and 3.9.0a4 are now available
by Łukasz Langa Feb. 26, 2020

Feb. 26, 2020

On behalf of the entire Python development community, and the currently serving Python release team in particular, I’m pleased to announce the release of two of the latest Python editions. Python 3.8.2 Python 3.8.2 is the second maintenance release of Python 3.8 and contains two months worth of bug fixes. Detailed information about all changes made in 3.8.2 can be found in its change log <https://docs.python.org/release/3.8.2/whatsnew/changelog.html#python-3-8-2-…>. Note that compared … [View More]

1 0

PEP 614: Relaxing Grammar Restrictions On Decorators
by Brandt Bucher Feb. 23, 2020

Feb. 23, 2020

PEP 614 has recently completed a round of review on Python-Ideas: https://www.python.org/dev/peps/pep-0614/ It proposes that the current decorator syntax restrictions be relaxed to allow any valid expression. Nobody has raised any objections, but I wanted to gather more feedback here prior to bringing it before the Steering Council. Please let me know what you think... thanks! :)

2 2

Comments on PEP 558 (Defined semantics for locals() )
by Mark Shannon Feb. 22, 2020

Feb. 22, 2020

Hi, First of all I want to say that I'm very much in favour of the general idea behind PEP 558. Defined semantics is always better than undefined semantics :) However, I think there are a few changes needed: 1. Don't add anything to the C API, please. Frame attributes can be accessed via `PyObject_GetAttr[String]`. 2. Don't make the behaviour dependent on whether "tracing" is turned on. Doing so forces debuggers to use sys.settrace which is horribly slow. It also makes the … [View More]

2 6

Summary of Python tracker Issues
by Python tracker Feb. 21, 2020

Feb. 21, 2020

ACTIVITY SUMMARY (2020-02-14 - 2020-02-21) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7315 (+38) closed 44150 (+43) total 51465 (+81) Open issues with patches: 2874 Issues opened (62) ================== #38691: importlib: PYTHONCASEOK should be ignored when using python3 - https://bugs.python.org/issue38691 reopened by vstinner #39636: Can't … [View More]

1 0