Mailman 3 November 2020 - Python-Dev

Review patch fixing packed bitfields in ctypes struct/union
by Filipe Laíns Jan. 2, 2021

Jan. 2, 2021

Hi folks, I know this is a high-volume list so sorry for being yet another voice screaming into your mailbox, but I do not know how else to handle this. A few months ago, I opened a pull request fixing packed bitfields in ctypes struct/union, which right now are being incorrectly created. The offsets and size are all wrong in some cases, fields which should be packed end up with padding between them. bpo: https://bugs.python.org/issue29753 PR: https://github.com/python/cpython/pull/19850 Since ctypes has no maintainer it has been very hard tracking down someone who is up to review this. So, if this issue sparks some interest to you, or you just want to help me out, please have a look :) Cheers, Filipe Laíns

4 4

Thoughts on PEP 634 (Structural Pattern Matching)
by Mark Shannon Dec. 27, 2020

Dec. 27, 2020

Hi everyone, PEP 634/5/6 presents a possible implementation of pattern matching for Python. Much of the discussion around PEP 634, and PEP 622 before it, seems to imply that PEP 634 is synonymous with pattern matching; that if you reject PEP 634 then you are rejecting pattern matching. That simply isn't true. Can we discuss whether we want pattern matching in Python and the broader semantics first, before dealing with low level details? Do we want pattern matching in Python at all? --------------------------------------------- Pattern matching works really well in statically typed, functional languages. The lack of mutability, constrained scope and the ability of the compiler to distinguish let variables from constants means that pattern matching code has fewer errors, and can be compiled efficiently. Pattern matching works less well in dynamically-typed, functional languages and statically-typed, procedural languages. Nevertheless, it works well enough for it to be a popular feature in both erlang and rust. In dynamically-typed, procedural languages, however, it is not clear (at least not to me) that it works well enough to be worthwhile. That is not say that pattern matching could never be of value in Python, but PEP 635 fails to demonstrate that it can (although it does a better job than PEP 622). Should match be an expression, or a statement? ---------------------------------------------- Do we want a fancy switch statement, or a powerful expression? Expressions have the advantage of not leaking (like comprehensions in Python 3), but statements are easier to work with. Can pattern matching make it clear what is assigned? ---------------------------------------------------- Embedding the variables to be assigned into a pattern, makes the pattern concise, but requires discarding normal Python syntax and inventing a new sub-language. Could we make patterns fit Python better? Is it possible to make assignment to variables clear, and unambiguous, and allow the use of symbolic constants at the same time? I think it is, but PEP 634 fails to do this. How should pattern matching be integrated with the object model? ---------------------------------------------------------------- What special method(s) should be added? How and when should they be called? PEP 634 largely disregards the object model, meaning it has many special cases, and is inefficient. The semantics must be well defined. ----------------------------------- Language extensions PEPs should define the semantics of those extensions. For example, PEP 343 and PEP 380 both did. https://www.python.org/dev/peps/pep-0343/#specification-the-with-statement https://www.python.org/dev/peps/pep-0380/#formal-semantics PEP 634 just waves its hands and talks about undefined behavior, which horrifies me. In summary, I would ask anyone who wants pattern matching adding to Python, to not support PEP 634. PEP 634 just isn't a good fit for Python, and we deserve something better. Cheers, Mark.

8 8

pip 20.3 release (new resolver as default)
by Sumana Harihareswara Dec. 13, 2020

Dec. 13, 2020

On behalf of the PyPA and the pip team, I am pleased to announce that we have just released pip 20.3, a new version of pip. You can install it by running `python -m pip install --upgrade pip`. This is an important and disruptive release -- we [explained why in a blog post last year](https://pyfound.blogspot.com/2019/12/moss-czi-support-pip.html). We even made [a video about it](https://www.youtube.com/watch?v=B4GQCBBsuNU). ## Highlights * **DISRUPTION**: Switch to the new dependency resolver by default. (#9019) Watch out for changes in handling editable installs, constraints files, and more: https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-res… * **DEPRECATION**: Deprecate support for Python 3.5 (to be removed in pip 21.0) (#8181) * **DEPRECATION**: pip freeze will stop filtering the pip, setuptools, distribute and wheel packages from pip freeze output in a future version. To keep the previous behavior, users should use the new `--exclude` option. (#4256) * Substantial improvements in new resolver for performance, output and error messages, avoiding infinite loops, and support for constraints files. * Support for PEP 600: Future ‘manylinux’ Platform Tags for Portable Linux Built Distributions. (#9077) * Documentation improvements: Resolver migration guide, quickstart guide, and new documentation theme. * Add support for MacOS Big Sur compatibility tags. (#9138) The new resolver is now *on by default*. It is significantly stricter and more consistent when it receives incompatible instructions, and reduces support for certain kinds of constraints files, so some workarounds and workflows may break. Please see [our guide on how to test and migrate, and how to report issues](https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-resolver-in-20-3-2020). You can use the deprecated (old) resolver, using the flag `--use-deprecated=legacy-resolver`, until we remove it in the pip 21.0 release in January 2021. You can find more details (including deprecations and removals) [in the changelog](https://pip.pypa.io/en/stable/news/). ## User experience Command-line output for this version of pip, and documentation to help with errors, is significantly better, because you worked with our experts to test and improve it. [Contribute to our user experience work: sign up to become a member of the UX Studies group](https://bit.ly/pip-ux-studies) (after you join, we'll notify you about future UX surveys and interviews). ## What to expect in 20.1 We aim to release pip 20.1 in January 2021, per our [usual release cadence](https://pip.pypa.io/en/latest/development/release-process/#release-cadence). You can expect: * Removal of [Python 2.7](https://pip.pypa.io/en/latest/development/release-process/#python-2-support) and 3.5 support * Further improvements in the new resolver * Removal of legacy resolver support ## Thanks As with all pip releases, a significant amount of the work was contributed by pip's user community. Huge thanks to all who have contributed, whether through code, documentation, issue reports and/or discussion. Your help keeps pip improving, and is hugely appreciated. Specific thanks go to Mozilla (through its [Mozilla Open Source Support](https://www.mozilla.org/en-US/moss/) Awards) and to the [Chan Zuckerberg Initiative](https://chanzuckerberg.com/eoss/) DAF, an advised fund of Silicon Valley Community Foundation, for their funding that enabled substantial work on the new resolver. That funding went to [Simply Secure](https://simplysecure.org/) (specifically Georgia Bullen, Bernard Tyers, Nicole Harris, Ngọc Triệu, and Karissa McKelvey), [Changeset Consulting](https://changeset.nyc/) (Sumana Harihareswara), [Atos](https://www.atos.net) (Paul F. Moore), [Tzu-ping Chung](https://uranusjr.com), [Pradyun Gedam](https://pradyunsg.me/), and Ilan Schnell. Thanks also to Ernest W. Durbin III at the Python Software Foundation for liaising with the project. -Sumana Harihareswara, pip project manager

2 2

Ideas for improving the contribution experience
by Tal Einat Dec. 8, 2020

Dec. 8, 2020

(Context: Continuing to prepare for the core dev sprint next week. Since the sprint is near, *I'd greatly appreciate any quick comments, feedback and ideas!*) Following up my collection of past beginning contributor experiences, I've collected these experiences in a dedicated GitHub repo[1] and written a (subjective!) summary of main themes that I recognize in the stories, which I've also included in the repo[2]. A "TL;DR" bullet list of those main themes: * Slow/no responsiveness * Long, slow process * Hard to find where to contribute * Mentorship helps a lot, but is scarce * A lot to learn to get started * It's intimidating More specifically, something that has come up often is that maintaining momentum for new contributors is crucial for them to become long-term contributors. Most often, this comes up in relation to the first two points: Suggestions or PRs are completely receive no attention at all ("ignored") or stop receiving attention at some point ("lost to the void"). Unfortunately, the probability of this is pretty high for any issue/PR, so for a new contributor this is almost guaranteed to happen while working on one of their first few contributions. I've seen this happen many times, and have found that I have to personally follow promising contributors' work to ensure that this doesn't happen to them. I've also seen contributors learn to actively seek out core devs when these situations arise, which is often a successful tactic, but shouldn't be necessary so often. Now, this is in large part a result of the fact that us core devs are not a very large group, made up almost entirely of volunteers working on this in their spare time. Last I checked, the total amount of paid development time dedicated to developing Python is less than 3 full-time (i.e. ~100 hours a week). The situation being problematic is clear enough that the PSF had concrete plans to hire paid developers to review issues and PRs. However, those plans have been put on hold indefinitely, since the PSF's funding has shrunk dramatically since the COVID-19 outbreak (no PyCon!). So, what can be done? Besides raising more funds (see a note on this below), I think we can find ways to reduce how often issues/PRs become "stalled". Here are some ideas: 1. *Generate reminders for reviewers when an issue or PR becomes "stalled' due to them.* Personally, I've found that both b.p.o. and GitHub make it relatively hard to remember to follow up on all of the many issues/PRs you've taken part in reviewing. It takes considerable attention and discipline to do so consistently, and reminders like these would have helped me. Many (many!) times, all it took to get an issue/PR moving forward (or closed) was a simple "ping?" comment. 2. *Generate reminders for contributors when an issue or PR becomes "stalled" due to them.* Similar to the above, but I consider these separate. 3. *Advertise something like a "2-for-1" standing offer for reviews.* This would give contributors an "official", acceptable way to get attention for their issue/PR, other than "begging" for attention on a mailing list. There are good ways for new contributors to be of significant help despite being new to the project, such as checking whether old bugs are still relevant, searching for duplicate issues, or applying old patches to the current code and creating a PR. (This would be similar to Martin v. Löwis's 5-for-1 offer in 2012[3], which had little success but lead to some interesting followup discussion[4]). 4. *Encourage core devs to dedicate some of their time to working through issues/PRs which are "ignored" or "stalled".* This would require first generating reliable lists of issues/PRs in such states. This could be in various forms, such as predefined GitHub/b.p.o. queries, a dedicated web-page, a periodic message similar to b.p.o.'s "weekly summary" email, or dedicated tags/labels for issues/PRs. (Perhaps prioritize "stalled" over "ignored".) - Tal Einat [1]: https://github.com/taleinat/python-contribution-feedback [2]: https://github.com/taleinat/python-contribution-feedback/blob/master/Takeaw… [3]: https://mail.python.org/archives/list/python-dev@python.org/message/7DLUN4Y… [4]: https://mail.python.org/archives/list/python-dev@python.org/thread/N4MMHXXO…

7 8

Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead
by Paul Sokolovsky Dec. 6, 2020

Dec. 6, 2020

Hello, As was mentioned many times on the list, PEP634-PEP636 are thoroughly prepared and good materials, many thanks to their authors. PEP635 "Motivation and Rationale" (https://www.python.org/dev/peps/pep-0635/) stands out among the 3 however: while reading it, chances that you'll get a feeling of "residue", accumulating a section over section. By the end of reading, you may get a well-formed feeling that you've read a half-technical, half-marketing material, which is intended to "sell" a particular idea among many other very viable ideas, by shoehorning some concepts, downplaying other ideas, and at the same time, light-heartedly presenting drawbacks of its subject one. Just to give one example, literally at the very beginning, at the "Pattern Matching and OO" section (3rd heading) it says: > Pattern matching is complimentary to the object-oriented paradigm. It's not until the very end of document, in the "History and Context" it tells the whole truth: > With its emphasis on abstraction and encapsulation, object-oriented > programming posed a serious challenge to pattern matching. You may wonder how "complimentary" and "posed a serious challenge" relate to each other. While they're definitely not contradictory, starting the document with light-hearted "complimentary" can be seen as trying to set the stage where readers don't pay enough attention to the problem. And it kinda worked: only now [1] wider community discovers the implications of "Class Patterns" choices. (As a note, PEP635 does well on explaining them, and I'm personally sold on that, but it's *tough* choice, not the *obvious* choice). There're many more examples like that in the PEP635, would take too much space to list them all. However, PEP635 refers to the paper: > Kohn et al., Dynamic Pattern Matching with Python > https://doi.org/10.1145/3426422.3426983 (Accepted by DLS 2020. The > link will go live after Nov. 17; a preview PDF can be obtained from > the first author.) As that citation suggests, the paper is not directly linked from the PEP635. But the preprint is now accessible from the conference page, https://conf.researchr.org/home/dls-2020?#event-overview (direct link as of now: https://gvanrossum.github.io//docs/PyPatternMatching.pdf). That paper is written at much higher academic standard, and a pleasure to read. I recommend it to everyone who read PEP635 (note that it was written with PEP622 in mind, but conceptual differences are minor). With it, I noticed just 2 obvious issues: Section 4.3. Named Constants > It would clearly be desirable to allow named constants in patterns > as a replacement and extension of literals. However, Python has no > concept of a constant, i.e. all variables are mutable (even where > the values themselves are immutable). So, unlike PEP635, the paper pinpoints right the root of PEP634's problems: lack of constants in Python (on the language level). This is just the point which was raised on the mailing list either (https://mail.python.org/archives/list/python-dev@python.org/message/WV2UA4A…). Under strict academic peer review, the paper would have been returned for elaboration, with a note like: "Given that nowadays many dynamic languages (PHP, JavaScript, Lua, etc.) have support for constants, and lack of constants poses a serious usability challenge to your proposal, please explain why you chose to proceed anyway (and apply workarounds), instead of first introducing the concept of constants to the language. (Given that amount of work to implement pattern matching is certainly an order of magnitude larger than to introduce constants)." But the paper wasn't returned for elaboration, so we'll keep wondering why the authors chose such a backward process. Section 6.1. Scope > The granularity of the scope of local variables is at the level of > functions and frames. [...] > The only way to restrict the scope of a variable to part of a > function’s body (such as a case clause) would be to actively delete > the variable when leaving the block. This would, however, not restore > any previous value of a local variable in the function’s scope. This is a misconception ("the only way") which is repeated almost one to one on PEP635 either. If anything, the above describes how pseudo-scoping is currently implemented for exception vars in "except Exception as e:" clause (more info: https://mail.python.org/pipermail/python-dev/2019-January/155991.html), which is hardly a "best practice", and definitely not the only way. How to support multiple variable scopes in one stack frame is not a rocket science at all. One just need to remember how C did that since ~forever. And that's: (for unoptimized programs) variables in different scopes live in disjoint subsections of a frame. (For optimized programs, variables with disjoint liveness can share the same locations in a frame). The only reasons for not implementing the same solution in Python would be intertia of thought and "but it's not done anywhere else in Python". Yeah, but nobody del'eted local variables behind users' backs either, before somebody started to do that for exception clause variables. And the whole of pattern matching is such that either one thing, or another, but will be done for the first time in Python. For example, nobody before could imagine that one can write "Point(x, y)", and get x and y assigned, and now we're facing just that [1]. (Again, I personally love it, though think that "Point(>x, >y)" is an interesting option to address the tensions). In that regard, the current PEP634 and friends miss too many interesting and useful opportunities (constants in language core and true scoping for match'es, to name a few). Well, that happens. But they try to shoehorn too much of "we didn't do" into "it's not possible" or "it doesn't make sense", or "let's workaround it in adhoc ways" and that raises eyebrows, leading to concerns of whether the proposals are actually "raw" as of yet. [1] People expressing surprise at "Class Patterns" syntax: https://mail.python.org/archives/list/python-dev@python.org/message/F66J72J… https://mail.python.org/archives/list/python-dev@python.org/message/Q2ARJUL… -- Best regards, Paul mailto:pmiscml@gmail.com

10 23

Re: Distro packagers: PEP 615 and the tzdata dependency
by Tianon Gravi Nov. 30, 2020

Nov. 30, 2020

> I'd love to have an easy way to keep them in the loop. I'm one of the maintainers on https://github.com/docker-library/python (which is what results in https://hub.docker.com/_/python), and I'd love to have an easy way to keep myself in the loop too! O:) Is there a lower-frequency mailing list where things like this are normally posted that I could follow? (I don't want to be a burden, although we'd certainly really love to have more upstream collaboration on that repo -- we do our best to represent upstream as correctly/accurately as possible, but we're not experts!) > would it make sense to add a packaging section to our documentation or > to write an informational PEP? FWIW, I love the idea of an explicit "packaging" section in the docs (or a PEP), but I've maintained that for other projects before and know it's not always easy or obvious. :) ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4 PS. thanks doko for giving me a link to this thread! :D

8 9

Summary of Python tracker Issues
by Python tracker Nov. 27, 2020

Nov. 27, 2020

ACTIVITY SUMMARY (2020-11-20 - 2020-11-27) 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 7579 (-14) closed 46642 (+80) total 54221 (+66) Open issues with patches: 3054 Issues opened (37) ================== #28468: Add platform.freedesktop_os_release() https://bugs.python.org/issue28468 reopened by christian.heimes #42392: remove the 'loop' parameter from __init__ in all classes in as https://bugs.python.org/issue42392 reopened by yselivanov #42413: Replace custom exceptions for timeouts with TimeoutError https://bugs.python.org/issue42413 reopened by christian.heimes #42422: Py_Decref on value crash the interpreter in Python/ceval.c:110 https://bugs.python.org/issue42422 opened by sbz #42425: Possible leak in initialization of errmap for OSError https://bugs.python.org/issue42425 opened by serhiy.storchaka #42429: Behavior of general (%g, :g) formatting inconsistent for decim https://bugs.python.org/issue42429 opened by Kwpolska #42431: Fix outdated bytes comments https://bugs.python.org/issue42431 opened by serhiy.storchaka #42433: mailbox.mbox fails on non ASCII characters https://bugs.python.org/issue42433 opened by flokli #42434: Library json, file json/encoder.py: Function floatstr should b https://bugs.python.org/issue42434 opened by salacdav #42436: Google use wrong "hightlight" argument https://bugs.python.org/issue42436 opened by amirouche #42437: crypt produces wrong hashes for passwords containing dollar si https://bugs.python.org/issue42437 opened by m.stoichkovaaa #42442: Tarfile to stdout documentation example https://bugs.python.org/issue42442 opened by ilaughlin #42443: Provide Thread creation hook support https://bugs.python.org/issue42443 opened by stanczyk #42444: pathlib.PurePath properties annotated with .. data directive https://bugs.python.org/issue42444 opened by p-ganssle #42447: robotsparser deny all with some rules https://bugs.python.org/issue42447 opened by contact #42451: Indicate in the docs that PyTuple_GetItem does not support neg https://bugs.python.org/issue42451 opened by Antony.Lee #42452: FIX Optimize 'rgb_to_hls' https://bugs.python.org/issue42452 opened by jjerphan #42454: Move slice creation to the compiler for constants https://bugs.python.org/issue42454 opened by BTaskaya #42455: Add decorator_with_params function to functools module https://bugs.python.org/issue42455 opened by uriyyo #42457: ArgumentParser nested subparsers resolve paths in improper ord https://bugs.python.org/issue42457 opened by carsonwilber #42461: os.statvfs_result doesn't show f_fsid https://bugs.python.org/issue42461 opened by Rethan #42464: Pathlib resolve() resolves non-existent ".." components with s https://bugs.python.org/issue42464 opened by john.engelke #42465: Reference to subclass method resolve() in PurePath docs https://bugs.python.org/issue42465 opened by john.engelke #42466: asyncio loop.getaddrinfo raises RuntimeError https://bugs.python.org/issue42466 opened by kappa #42469: Space in re's {min,max} should raise an error, rather than fai https://bugs.python.org/issue42469 opened by reuven #42470: DeprecationWarning triggers for sequences which happen to be s https://bugs.python.org/issue42470 opened by xmorel #42471: Slowdown in socket tests noticed since Py3.8 https://bugs.python.org/issue42471 opened by X-Istence #42474: improve test coverage for TracebackException's __eq__ https://bugs.python.org/issue42474 opened by iritkatriel #42476: Allow cross compiling python for macos-arm64 from macos-x86_64 https://bugs.python.org/issue42476 opened by isuruf #42477: ip_interface addition and subtraction changes netmask https://bugs.python.org/issue42477 opened by wyko.ter.haar #42478: ipaddress.IPv4network.interfaces() https://bugs.python.org/issue42478 opened by wyko.ter.haar #42480: Python Tkinter crashes on macOS 11.1 beta https://bugs.python.org/issue42480 opened by kode54 #42481: Add to pathlib function to check permission similar to os.acce https://bugs.python.org/issue42481 opened by copalco #42482: TracebackException should not hold reference to the exception https://bugs.python.org/issue42482 opened by iritkatriel #42483: Way working directory is added to sys.path differs between usi https://bugs.python.org/issue42483 opened by plammens #42484: parse_message_id, get_msg_id, get_obs_local_part is poorly wri https://bugs.python.org/issue42484 opened by dxn126 #42485: Full grammar specification should link to PEP 617 https://bugs.python.org/issue42485 opened by snoopjedi Most recent 15 issues with no replies (15) ========================================== #42485: Full grammar specification should link to PEP 617 https://bugs.python.org/issue42485 #42484: parse_message_id, get_msg_id, get_obs_local_part is poorly wri https://bugs.python.org/issue42484 #42483: Way working directory is added to sys.path differs between usi https://bugs.python.org/issue42483 #42477: ip_interface addition and subtraction changes netmask https://bugs.python.org/issue42477 #42465: Reference to subclass method resolve() in PurePath docs https://bugs.python.org/issue42465 #42464: Pathlib resolve() resolves non-existent ".." components with s https://bugs.python.org/issue42464 #42457: ArgumentParser nested subparsers resolve paths in improper ord https://bugs.python.org/issue42457 #42452: FIX Optimize 'rgb_to_hls' https://bugs.python.org/issue42452 #42451: Indicate in the docs that PyTuple_GetItem does not support neg https://bugs.python.org/issue42451 #42444: pathlib.PurePath properties annotated with .. data directive https://bugs.python.org/issue42444 #42442: Tarfile to stdout documentation example https://bugs.python.org/issue42442 #42434: Library json, file json/encoder.py: Function floatstr should b https://bugs.python.org/issue42434 #42409: Interpreter exit blocks waiting for ThreadPoolExecutor.map https://bugs.python.org/issue42409 #42408: passing memoryview slice to struct packing functions https://bugs.python.org/issue42408 #42406: Importing multiprocessing breaks pickle.whichmodule https://bugs.python.org/issue42406 Most recent 15 issues waiting for review (15) ============================================= #42485: Full grammar specification should link to PEP 617 https://bugs.python.org/issue42485 #42482: TracebackException should not hold reference to the exception https://bugs.python.org/issue42482 #42476: Allow cross compiling python for macos-arm64 from macos-x86_64 https://bugs.python.org/issue42476 #42474: improve test coverage for TracebackException's __eq__ https://bugs.python.org/issue42474 #42461: os.statvfs_result doesn't show f_fsid https://bugs.python.org/issue42461 #42455: Add decorator_with_params function to functools module https://bugs.python.org/issue42455 #42454: Move slice creation to the compiler for constants https://bugs.python.org/issue42454 #42451: Indicate in the docs that PyTuple_GetItem does not support neg https://bugs.python.org/issue42451 #42443: Provide Thread creation hook support https://bugs.python.org/issue42443 #42434: Library json, file json/encoder.py: Function floatstr should b https://bugs.python.org/issue42434 #42431: Fix outdated bytes comments https://bugs.python.org/issue42431 #42425: Possible leak in initialization of errmap for OSError https://bugs.python.org/issue42425 #42422: Py_Decref on value crash the interpreter in Python/ceval.c:110 https://bugs.python.org/issue42422 #42415: python3.lib in Python3.9.0 Windows distribution does not conta https://bugs.python.org/issue42415 #42413: Replace custom exceptions for timeouts with TimeoutError https://bugs.python.org/issue42413 Top 10 most discussed issues (10) ================================= #28468: Add platform.freedesktop_os_release() https://bugs.python.org/issue28468 41 msgs #42413: Replace custom exceptions for timeouts with TimeoutError https://bugs.python.org/issue42413 15 msgs #41818: Lib/pty.py major revision https://bugs.python.org/issue41818 10 msgs #42454: Move slice creation to the compiler for constants https://bugs.python.org/issue42454 10 msgs #42392: remove the 'loop' parameter from __init__ in all classes in as https://bugs.python.org/issue42392 9 msgs #36906: Compile time textwrap.dedent() equivalent for str or bytes lit https://bugs.python.org/issue36906 8 msgs #42411: respect cgroups limits when trying to allocate memory https://bugs.python.org/issue42411 8 msgs #41100: Support macOS 11 and Apple Silicon Macs https://bugs.python.org/issue41100 7 msgs #42422: Py_Decref on value crash the interpreter in Python/ceval.c:110 https://bugs.python.org/issue42422 6 msgs #42429: Behavior of general (%g, :g) formatting inconsistent for decim https://bugs.python.org/issue42429 5 msgs Issues closed (81) ================== #4657: Doctest gets line numbers wrongs with <> in name https://bugs.python.org/issue4657 closed by iritkatriel #8733: list type and UserList do not call super in __init__ and there https://bugs.python.org/issue8733 closed by rhettinger #13907: test_pprint relies on set/dictionary repr() ordering https://bugs.python.org/issue13907 closed by rhettinger #15450: Allow dircmp.subdirs to behave well under subclassing https://bugs.python.org/issue15450 closed by asvetlov #16346: maximum recursion installing readline package https://bugs.python.org/issue16346 closed by iritkatriel #17695: _sysconfigdata broken with universal builds on OSX https://bugs.python.org/issue17695 closed by ronaldoussoren #18212: No way to check whether Future is finished? https://bugs.python.org/issue18212 closed by iritkatriel #21041: pathlib.PurePath.parents rejects negative indexes https://bugs.python.org/issue21041 closed by p-ganssle #21564: Declaration of EVP_MD_CTX causes crash when switching between https://bugs.python.org/issue21564 closed by iritkatriel #26878: Allow doctest to deep copy globals https://bugs.python.org/issue26878 closed by iritkatriel #27839: "Python [...] calls sys.displayhook() on unhandled exceptions" https://bugs.python.org/issue27839 closed by iritkatriel #28002: ast.unparse can't roundtrip some f-strings https://bugs.python.org/issue28002 closed by BTaskaya #28850: Regression in Python 3: Subclassing PrettyPrinter.format doesn https://bugs.python.org/issue28850 closed by taleinat #28913: "Fatal Python error: Cannot recover from stack overflow." from https://bugs.python.org/issue28913 closed by iritkatriel #29207: make install fails on ARM https://bugs.python.org/issue29207 closed by iritkatriel #29573: NamedTemporaryFile with delete=True should not fail if file al https://bugs.python.org/issue29573 closed by iritkatriel #31713: python3 python-config script generates invalid includes https://bugs.python.org/issue31713 closed by iritkatriel #32317: sys.exc_clear() clears exception in other stack frames https://bugs.python.org/issue32317 closed by iritkatriel #33167: RFC Documentation Updates to urllib.parse.rst https://bugs.python.org/issue33167 closed by iritkatriel #37317: asyncio gather doesn't handle custom exceptions that inherit f https://bugs.python.org/issue37317 closed by iritkatriel #37718: 2to3 exception handling https://bugs.python.org/issue37718 closed by iritkatriel #37865: tempfile.NamedTemporaryFile() raises exception on close() when https://bugs.python.org/issue37865 closed by iritkatriel #38443: unavailable --with-universal-archs= macOS confgure options fai https://bugs.python.org/issue38443 closed by ned.deily #38638: Backtrace of exit phase of context managers https://bugs.python.org/issue38638 closed by iritkatriel #40550: Popen.terminate fails with ProcessLookupError under certain co https://bugs.python.org/issue40550 closed by gregory.p.smith #40791: hmac.compare_digest could try harder to be constant-time. https://bugs.python.org/issue40791 closed by benjamin.peterson #40840: lzma.h file not found building on macOS https://bugs.python.org/issue40840 closed by jaraco #40857: tempfile.TemporaryDirectory() context manager can fail to prop https://bugs.python.org/issue40857 closed by iritkatriel #40934: Default RLock does not work well for Manager Condition https://bugs.python.org/issue40934 closed by iritkatriel #41015: warning: 'sqlite3_enable_shared_cache' is deprecated https://bugs.python.org/issue41015 closed by ronaldoussoren #41332: connect_accepted_socket() missing from AbstractEventLoop https://bugs.python.org/issue41332 closed by asvetlov #41442: test_posix.PosixTester.test_getgroups fail on operating system https://bugs.python.org/issue41442 closed by pxinwr #41562: StreamReaderProtocol inheritance https://bugs.python.org/issue41562 closed by asvetlov #41655: New Node may not be visited in lib2to3.refactor.RefactoringToo https://bugs.python.org/issue41655 closed by gregory.p.smith #41878: python3 fails to use custom mapping object as symbols in eval( https://bugs.python.org/issue41878 closed by josh.r #42120: Depreciated MACRO of copysign for MSVC https://bugs.python.org/issue42120 closed by steve.dower #42202: Optimize function annotation https://bugs.python.org/issue42202 closed by methane #42212: Check if generated files are up-to-date in Github Actions https://bugs.python.org/issue42212 closed by vstinner #42232: mmap module add Darwin specific madvise options https://bugs.python.org/issue42232 closed by ronaldoussoren #42299: Remove formatter module https://bugs.python.org/issue42299 closed by corona10 #42336: Make PCbuild/build.bat build x64 by default https://bugs.python.org/issue42336 closed by steve.dower #42349: Compiler front-end produces a broken CFG https://bugs.python.org/issue42349 closed by Mark.Shannon #42360: In the namedtuple documentation, mention that typename should https://bugs.python.org/issue42360 closed by rhettinger #42391: Clarify documentation of TestCase.assertIs https://bugs.python.org/issue42391 closed by terry.reedy #42395: aclosing was not added to __all__ in contextlib https://bugs.python.org/issue42395 closed by asvetlov #42407: Grammatical typo in multiprocessing doc https://bugs.python.org/issue42407 closed by terry.reedy #42410: Raise a pickleError when convert _functools module to use PyTy https://bugs.python.org/issue42410 closed by shihai1991 #42412: Fix bases issues in PyType_FromModuleAndSpec() https://bugs.python.org/issue42412 closed by serhiy.storchaka #42419: Typo in "what's new in Python 3.9" https://bugs.python.org/issue42419 closed by iritkatriel #42420: queue.Queue().join() add a timeout option https://bugs.python.org/issue42420 closed by rhettinger #42421: Native open failed to create a file on windows10 when colon ex https://bugs.python.org/issue42421 closed by steven.daprano #42423: Support passing single class to PyType_FromSpecWithBases and P https://bugs.python.org/issue42423 closed by serhiy.storchaka #42424: add constructor that support multiple context managers to cont https://bugs.python.org/issue42424 closed by serhiy.storchaka #42426: IDLE: Fix reporting RE error in searchengine https://bugs.python.org/issue42426 closed by terry.reedy #42427: Use the errno attribute of OSError instead of args[0] https://bugs.python.org/issue42427 closed by serhiy.storchaka #42428: Inconsistent squaring behavior https://bugs.python.org/issue42428 closed by christian.heimes #42430: Windows py launcher default for shebang line is surprising https://bugs.python.org/issue42430 closed by gvanrossum #42432: Http client, Bad Status Line triggered for no reason https://bugs.python.org/issue42432 closed by sicarius #42435: Speed up comparison of bytes and bytearray object with objects https://bugs.python.org/issue42435 closed by serhiy.storchaka #42438: Fatal Python error: init_fs_encoding: failed to get the Python https://bugs.python.org/issue42438 closed by eryksun #42439: Use of ternary operator instead of if and else in month calcul https://bugs.python.org/issue42439 closed by serhiy.storchaka #42440: MACBOOK Python launcher https://bugs.python.org/issue42440 closed by ronaldoussoren #42441: UnicodeEncodeError https://bugs.python.org/issue42441 closed by eryksun #42445: Assertion in run_coroutine_threadsafe https://bugs.python.org/issue42445 closed by asvetlov #42446: Assertion error os.path.exists(pyc_path) while building Python https://bugs.python.org/issue42446 closed by thoradia #42448: re.findall have different match result against re.search or re https://bugs.python.org/issue42448 closed by HaujetZhao #42449: Adding number to a declared 2 dimension list https://bugs.python.org/issue42449 closed by eric.smith #42450: Docstrings in itertools recipes should have triple-quotes https://bugs.python.org/issue42450 closed by rhettinger #42453: utf-8 codec error when pip uninstalling a package which has fi https://bugs.python.org/issue42453 closed by vstinner #42456: Logical Error https://bugs.python.org/issue42456 closed by tim.peters #42458: Pathlib resolve() on Mac prepends path https://bugs.python.org/issue42458 closed by john.engelke #42459: Wrong Output https://bugs.python.org/issue42459 closed by steven.daprano #42460: Wrong Output https://bugs.python.org/issue42460 closed by steven.daprano #42462: Unacceptable Output https://bugs.python.org/issue42462 closed by eric.smith #42463: test_pty.test_openpty() failed on x86 Gentoo Installed with X https://bugs.python.org/issue42463 closed by vstinner #42467: slice().indices() returns incorrect values https://bugs.python.org/issue42467 closed by mark.dickinson #42468: subprocess.CompletedProcess: Add boolean value https://bugs.python.org/issue42468 closed by gregory.p.smith #42472: security hole in eval() https://bugs.python.org/issue42472 closed by vstinner #42473: re.sub ignores flag re.M https://bugs.python.org/issue42473 closed by mrabarnett #42475: wrongly cache pattern by re.compile https://bugs.python.org/issue42475 closed by mrabarnett #42479: Canvas's create_image method not work in some situaction. https://bugs.python.org/issue42479 closed by MangoIceCup

1 0

[RELEASE] Python 3.9.1rc1 is now ready for testing
by Łukasz Langa Nov. 27, 2020

Nov. 27, 2020

Python 3.9.1rc1 is the release candidate of the first maintenance release of Python 3.9. Go get it here: https://www.python.org/downloads/release/python-391rc1/ <https://www.python.org/downloads/release/python-391rc1/> Assuming no critical problems are found prior to 2020-12-11, the currently scheduled release date for 3.9.1, no code changes are planned between this release candidate and the final release. That being said, please keep in mind that this is a pre-release of 3.9.1 and as such its main purpose is testing. Maintenance releases for the 3.9 series will continue at regular bi-monthly intervals, with 3.9.2 planned for end of January 2021. Installer news 3.9.1rc1 is the first version of Python to support macOS 11 Big Sur. With Xcode 11 and later it is now possible to build “Universal 2” binaries which work on Apple Silicon. We are providing such an installer as the macosx11.0 variant. This installer can be deployed back to older versions, tested down to OS X 10.9. As we are waiting for an updated version of pip, please consider the macosx11.0 installer experimental. This work would not have been possible without the effort of Ronald Oussoren, Ned Deily, and Lawrence D’Anna from Apple. Thank you! In other news, this is the first version of Python to default to the 64-bit installer on Windows. The installer now also actively disallows installation on Windows 7. Python 3.9 is incompatible with this unsupported version of Windows. What’s new in Python 3.9.1rc1? We’ve made 240 changes since v3.9.0 which is a significant amount. To compare, 3.8.1rc1 only saw 168 commits since 3.8.0. See the full change log at https://docs.python.org/release/3.9.1rc1/whatsnew/changelog.html <https://docs.python.org/release/3.9.1rc1/whatsnew/changelog.html>. For more information about features included in the 3.9 series, see the “What’s New in Python 3.9 <https://docs.python.org/release/3.9.0/whatsnew/3.9.html>” document. What about Python 3.8.7rc1? There’s additional work needed to make this release support macOS 11 Big Sur. This should be ready next week, stay tuned. We hope you enjoy the new releases! Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf/ <https://www.python.org/psf/> More resources Online Documentation <https://docs.python.org/3.9/> PEP 596 <https://www.python.org/dev/peps/pep-0596/>, 3.9 Release Schedule PEP 619 <https://www.python.org/dev/peps/pep-0619/>, 3.10 Release Schedule Report bugs at https://bugs.python.org <https://bugs.python.org/>. Help fund Python and its community <https://www.python.org/psf/donations/>. Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>

2 1

Thanks for the Dev Guide
by Richard Levasseur Nov. 26, 2020

Nov. 26, 2020

Hi everyone, I just wanted to express some appreciation for the excellent Dev Guide. I don't use git or github much, but the dev guide got me from not knowing where to start, to having a PR out for review in a couple hours. It walked me through...pretty much perfectly. Getting a CLA signed was also simple and nice. When the bot brought that up, I thought it'd be a headache big enough to keep the PR from ever getting back to the top of my todo list. But the help text and links from the bot, the integration of BPO with Google sign in, linking BPO to a github name, digitally signing the CLA, the little heroku thing -- all just self serve, and easy, and obvious, and really just didn't get in the way. I don't know which person(s) are the best to thank for all that, but thanks for making it easy for a newbie to get started and contribute.

3 2

Questions about about the DLS 2020
by Mark Shannon Nov. 26, 2020

Nov. 26, 2020

Hi Tobias, A couple of questions about the DLS 2020 paper. 1. Why do you use the term "validate" rather than "test" for the process of selecting a match? It seems to me, that this is a test, not a validation, as no exception is raised if a case doesn't match. 2. Is the error in the ast matching example, an intentional "simplification" or just an oversight? The example: ``` def simplify(node): match node: case BinOp(Num(left), '+', Num(right)): return Num(left + right) case BinOp(left, '+' | '-', Num(0)): return simplify(left) case UnaryOp('-', UnaryOp('-', item)): return simplify(item) case _: return node ``` is wrong. The correct version is ``` def simplify(node): match node: case BinOp(Num(left), Add(), Num(right)): return Num(left + right) case BinOp(left, Add() | Sub(), Num(0)): return simplify(left) case UnaryOp(USub(), UnaryOp(USub(), item)): return simplify(item) case _: return node ``` Cheers, Mark.

8 15