Mailman 3 May 2021 - Python-Dev

Mixed Python/C debugging
by Skip Montanaro 26 Apr '23

26 Apr '23

Having tried comp.lang.python with no response, I turn here... After at least ten years away from Python's run-time interpreter & byte code compiler, I'm getting set to familiarize myself with that again. This will, I think, entail debugging a mixed Python/C environment. I'm an Emacs user and am aware that GDB since 7.0 has support for debugging at the Python code level. Is Emacs+GDB my best bet? Are there any Python IDEs which support C-level breakpoints and debugging? Thanks, Skip

5 6

PEP 448 review
by Guido van Rossum 29 Mar '23

29 Mar '23

I'm back, I've re-read the PEP, and I've re-read the long thread with "(no subject)". I think Georg Brandl nailed it: """ *I like the "sequence and dict flattening" part of the PEP, mostly because itis consistent and should be easy to understand, but the comprehension syntaxenhancements seem to be bad for readability and "comprehending" what the codedoes.The call syntax part is a mixed bag on the one hand it is nice to be consistent with the extended possibilities in literals (flattening), but on the other hand there would be small but annoying inconsistencies anyways (e.g. the duplicate kwarg case above).* """ Greg Ewing followed up explaining that the inconsistency between dict flattening and call syntax is inherent in the pre-existing different rules for dicts vs. keyword args: {'a':1, 'a':2} results in {'a':2}, while f(a=1, a=2) is an error. (This form is a SyntaxError; the dynamic case f(a=1, **{'a': 1}) is a TypeError.) For me, allowing f(*a, *b) and f(**d, **e) and all the other combinations for function calls proposed by the PEP is an easy +1 -- it's a straightforward extension of the existing pattern, and anybody who knows what f(x, *a) does will understand f(x, *a, y, *b). Guessing what f(**d, **e) means shouldn't be hard either. Understanding the edge case for duplicate keys with f(**d, **e) is a little harder, but the error messages are pretty clear, and it is not a new edge case. The sequence and dict flattening syntax proposals are also clean and logical -- we already have *-unpacking on the receiving side, so allowing *x in tuple expressions reads pretty naturally (and the similarity with *a in argument lists certainly helps). From here, having [a, *x, b, *y] is also natural, and then the extension to other displays is natural: {a, *x, b, *y} and {a:1, **d, b:2, **e}. This, too, gets a +1 from me. So that leaves comprehensions. IIRC, during the development of the patch we realized that f(*x for x in xs) is sufficiently ambiguous that we decided to disallow it -- note that f(x for x in xs) is already somewhat of a special case because an argument can only be a "bare" generator expression if it is the only argument. The same reasoning doesn't apply (in that form) to list, set and dict comprehensions -- while f(x for x in xs) is identical in meaning to f((x for x in xs)), [x for x in xs] is NOT the same as [(x for x in xs)] (that's a list of one element, and the element is a generator expression). The basic premise of this part of the proposal is that if you have a few iterables, the new proposal (without comprehensions) lets you create a list or generator expression that iterates over all of them, essentially flattening them: >>> xs = [1, 2, 3] >>> ys = ['abc', 'def'] >>> zs = [99] >>> [*xs, *ys, *zs] [1, 2, 3, 'abc', 'def', 99] >>> But now suppose you have a list of iterables: >>> xss = [[1, 2, 3], ['abc', 'def'], [99]] >>> [*xss[0], *xss[1], *xss[2]] [1, 2, 3, 'abc', 'def', 99] >>> Wouldn't it be nice if you could write the latter using a comprehension? >>> xss = [[1, 2, 3], ['abc', 'def'], [99]] >>> [*xs for xs in xss] [1, 2, 3, 'abc', 'def', 99] >>> This is somewhat seductive, and the following is even nicer: the *xs position may be an expression, e.g.: >>> xss = [[1, 2, 3], ['abc', 'def'], [99]] >>> [*xs[:2] for xs in xss] [1, 2, 'abc', 'def', 99] >>> On the other hand, I had to explore the possibilities here by experimenting in the interpreter, and I discovered some odd edge cases (e.g. you can parenthesize the starred expression, but that seems a syntactic accident). All in all I am personally +0 on the comprehension part of the PEP, and I like that it provides a way to "flatten" a sequence of sequences, but I think very few people in the thread have supported this part. Therefore I would like to ask Neil to update the PEP and the patch to take out the comprehension part, so that the two "easy wins" can make it into Python 3.5 (basically, I am accepting two-thirds of the PEP :-). There is some time yet until alpha 2. I would also like code reviewers (Benjamin?) to start reviewing the patch <http://bugs.python.org/issue2292>, taking into account that the comprehension part needs to be removed. -- --Guido van Rossum (python.org/~guido)

7 17

PEP 638: Syntactic macros
by Mark Shannon 05 Feb '23

05 Feb '23

Hi everyone, I've submitted my PEP on syntactic macros as PEP 638. https://www.python.org/dev/peps/pep-0638/ All comments and suggestions are welcome. Cheers, Mark

16 25

How about using modern C++ in development of CPython ?
by redradist＠gmail.com 19 Oct '22

19 Oct '22

Hi all, What about of using modern C++ in developing CPython ? With C++ we can get the following benefits: 1) Readability - less code, most code is hidden by abstraction without losing performance 2) Maintainability - no code duplication in favor of using reusable classes 3) RAII - Resource Acquisition Is Initialization, predictable allocation and free resources ...

23 51

PEP 563 and Python 3.10.
by Thomas Wouters 22 Jul '22

22 Jul '22

(Starting a new thread so as not to derail any of the ongoing discussions.) Thanks, everyone, for your thoughts on Python 3.10 and the impact of PEP 563 (postponed evaluation of annotations) becoming the default. The Steering Council has considered the issue carefully, along with many of the proposed alternatives and solutions, and we’ve decided that at this point, we simply can’t risk the compatibility breakage of PEP 563. We need to roll back the change that made stringified annotations the default, at least for 3.10. (Pablo is already working on this.) To be clear, we are not reverting PEP 563 itself. The future import will keep working like it did since Python 3.7. We’re delaying making PEP 563 string-based annotations the default until Python 3.11. This will give us time to find a solution that works for everyone (or to find a feasible upgrade path for users who currently rely on evaluated annotations). Some considerations that led us to this decision: - PEP 563’s default change is clearly too disruptive to downstream users and third-party libraries to happen right now. We can’t risk breaking even a small subset of the FastAPI/pydantic users, not to mention other uses of evaluated type annotations that we’re not aware of yet. - PEP 563 provides no warning to users of the feature it’s disabling. Without that, we can’t expect users to be aware of the upcoming breakage. The lack of a warning was by design, and made sense in a world where type annotations were only consumed by static type checkers --- but that’s not actually the situation we’re in. There are clearly existing real-world, run-time uses of type annotations that would be adversely affected by this change. - Originally, PEP 563 was scheduled to take effect in Python 4, and this changed recently (after the discussion in the Language Summit of 2020). It's possible that third-party libraries and users didn’t plan to react in the current time frame as they were not aware of this change in timing. - There isn’t enough time to properly discuss PEP 649 or any of the alternatives before the beta 1 deadline, and we really need to make sure we don’t compound errors here. We need to look for a long term solution, which isn’t possible while still maintaining the release deadlines of Python 3.10. That means we’re also deferring PEP 649 to Python 3.11. In the Steering Council’s unanimous opinion, rolling back the default flip for stringified annotations in Python 3.10 is the least disruptive of all the options. We need to continue discussing the issue and potential solutions, since this merely postpones the problem until 3.11. (For the record, postponing the change further is not off the table, either, for example if the final decision is to treat evaluated annotations as a deprecated feature, with warnings on use.) For what it’s worth, the SC is also considering what we can do to reduce the odds of something like this happening again, but that’s a separate consideration, and a multi-faceted one at that. For the Steering Council, Thomas. -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

6 5

PEP 651, Robust Stack Overflow Handling, Rejection notice
by Python Steering Council 31 Jan '22

31 Jan '22

Hi Mark, Thank you for submitting PEP 651. The Steering Council has spent the past two weeks reviewing PEP 651. After careful consideration, we have decided to reject the PEP. The following were the key points that led us to this decision: * The benefits are not compelling enough. Deep recursion is not a common tool in Python, and even with PEP 651 it would not be efficient enough to make it a common tool. * The benefit of PEP 651 is negated as soon as a non-Python function is involved in the recursion, making the likelihood of it being useful even smaller. It also creates easy pitfalls for users who do end up relying on recursion. * We believe the PEP understates the disruption created by the technical solution of multiple Python stack frames per C call. Although this may be solvable, it will certainly cause substantial disruption to existing debuggers, tracers, and state inspection tools as they need to adapt to this change (which may not be trivial). * As the way to approach this will be platform-specific (as some parts of the proposal are not portable), this can cause generic Python code to behave differently on different platforms, making this kind of code less portable and less predictable. In the end, the benefit of the PEP does not outweigh the cost of the potential breakage, confusion, and unpredictability of the feature. With our appreciation, The Python Steering Council

6 8

PEP 646 (Variadic Generics): final call for comments
by Matthew Rahtz 18 Jan '22

18 Jan '22

Hi everyone, We've got to the stage now with PEP 646 that we're feeling pretty happy with it. So far though we've mainly been workshopping it in typing-sig, so as PEP 1 requires we're asking for some feedback here too before submitting it to the steering council. If you have time over the next couple of weeks, please take a look at the current draft and let us know your thoughts: https://www.python.org/dev/peps/pep-0646/ (Note that the final couple of sections are out of date; https://github.com/python/peps/pull/1880 clarifies which grammar changes would be required, now that PEP 637 has been rejected. We also have a second PR in progress at https://github.com/python/peps/pull/1881 clarifying some of the motivation.) Thanks! Matthew and Pradeep

9 19

Deprecate Py_TRASHCAN_SAFE_BEGIN/END in 3.10?
by Irit Katriel 19 Aug '21

19 Aug '21

Re https://bugs.python.org/issue40608. I think it will be an act of kindness to deprecate Py_TRASHCAN_SAFE_BEGIN/END in 3.10 and tell people to use Py_TRASHCAN_BEGIN/END instead. TL;DR: There was a change in 3.8 that introduced the latter while leaving the former for backwards compatibility, but also inadvertently breaking them. This is not an easy bug to deal with in the wild, we found it because we have a unit test in our codebase referencing https:// bugs.python.org/issue16602. A deprecation note pointing to the new macros would have made it easier. Is there any reason not to deprecate the old macros? Irit

7 13

Request for reviewers: pathlib improvements
by Barney Gale 01 Jul '21

01 Jul '21

I’m working towards supporting subclassing pathlib.Path for things like zip/tar archives, iso files, S3, etc. This was first brought up a few years ago in bpo-24132 <https://bugs.python.org/issue24132> and discussed further on the python-ideas forum <https://discuss.python.org/t/make-pathlib-extensible/3428>. Before I can approach the meat of the issue, I'd like to land a handful of backwards-compatible patches that tidy up the pathlib internals. These are: - #19220 <https://github.com/python/cpython/pull/19220> / bpo-39924 <https://bugs.python.org/issue39924>: Handle missing os functions more consistently in pathlib - #18838 <https://github.com/python/cpython/pull/18838> / bpo-39895 <https://bugs.python.org/issue39895>: Move pathlib.Path.touch() implementation into the path accessor - #19342 <https://github.com/python/cpython/pull/19342> / bpo-40038 <https://bugs.python.org/issue40038>: Remove partial support for preserving accessor when modifying a path - #18841 <https://github.com/python/cpython/pull/18841> / bpo-39899 <https://bugs.python.org/issue39899>: Make pathlib use os.path.expanduser() to expand home directories - #18834 <https://github.com/python/cpython/pull/18834> / bpo-39659 <https://bugs.python.org/issue39659>: Route calls from pathlib.Path to os.getcwd() via the path accessor - #18864 <https://github.com/python/cpython/pull/18864> / bpo-39906 <https://bugs.python.org/issue39906>: Add follow_symlinks parameter to pathlib.Path.stat() and chmod() - #24294 <https://github.com/python/cpython/pull/24294> / bpo-42999 <https://bugs.python.org/issue42999>: Expand and clarify pathlib.Path.link_to() documentation Could I please request review of these patches? A couple may already be ready to land. (I appreciate they’re a little dry. This is all prep work for the introduction of a shiny new class, tentatively named ‘AbstractPath’). Thanks! Barney

1 3

[RELEASE] Python 3.8.10, 3.9.5, and 3.10.0b1 are now available
by Łukasz Langa 11 Jun '21

11 Jun '21

This has been a very busy day for releases and on behalf of the Python development community we’re happy to announce the availability of three new Python releases. Python 3.10 is now in Beta Get it here: Python 3.10.0b1 <https://www.python.org/downloads/release/python-3100b1/> Python 3.10 is still in development. 3.10.0b1 is the first of four planned beta release previews. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We strongly encourage maintainers of third-party Python projects to test with 3.10 during the beta phase and report issues found to the Python bug tracker <https://bugs.python.org/> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Monday, 2021-08-02). Our goal is have no ABI changes after beta 4 and as few code changes as possible after 3.10.0rc1, the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.10 as possible during the beta phase. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next pre-release, the second beta release of Python 3.10, will be 3.10.0b2. It is currently scheduled for 2021-05-25. Please see PEP 619 <https://www.python.org/dev/peps/pep-0619/> for details. Development Begins on Python 3.11 With Python 3.10 moving to beta, it received its own 3.10 branch in the repository <https://github.com/python/cpython/>. All new features are now targeting Python 3.11, to be released in October 2022. Using the opportunity with the creation of the 3.10 branch, we renamed the master branch of the repository to main. It’s been a bit rocky <https://github.community/t/renaming-python-master-branch-to-main-1-4k-prs-7…> but looks like we’re open for business. Please rename the main branch of your personal fork using the guide GitHub will give you when you go to your fork’s main page. In case of any outstanding issues, please contact the 3.11 RM <https://devguide.python.org/devcycle/#current-administrators>. Python 3.9.5 Get it here: Python 3.9.5 <https://www.python.org/downloads/release/python-395/> Python 3.9.5 is the newest major stable release of the Python programming language, and it contains many new features and optimizations. There’s been 111 commits since 3.9.4 which is a similar amount compared to 3.8 at the same stage of the release cycle. See the change log <https://docs.python.org/release/3.9.5/whatsnew/changelog.html> for details. On macOS, we encourage you to use the universal2 variant whenever possible. The legacy 10.9+ Intel-only variant will not be provided for Python 3.10 and the universal2 variant will become the default download for future 3.9.x releases. You may need to upgrade third-party components, like pip, to later versions once they are released. You may experience differences in behavior in IDLE and other Tk-based applications due to using the newer version of Tk. As always, if you encounter problems when using this installer variant, please check https://bugs.python.org <https://bugs.python.org/> for existing reports and for opening new issues. The next Python 3.9 maintenance release will be 3.9.6, currently scheduled for 2021-06-28. The Last Regular Bugfix Release of Python 3.8 Get it here: Python 3.8.10 <https://www.python.org/downloads/release/python-3810/> According to the release calendar specified in PEP 569 <https://www.python.org/dev/peps/pep-0569/>, Python 3.8.10 is the final regular maintenance release. Starting now, the 3.8 branch will only accept security fixes and releases of those will be made in source-only form until October 2024. To keep receiving regular bug fixes, please upgrade to Python 3.9. Compared to the 3.7 series, this last regular bugfix release is relatively dormant at 92 commits since 3.8.9. Version 3.7.8, the final regular bugfix release of Python 3.7, included 187 commits. But there’s a bunch of important updates here regardless, the biggest being macOS Big Sur and Apple Silicon build support. This work would not have been possible without the effort of Ronald Oussoren, Ned Deily, Maxime Bélanger, and Lawrence D’Anna from Apple. Thank you! Take a look at the change log <https://docs.python.org/release/3.8.10/whatsnew/changelog.html> for details. We hope you enjoy the new releases Your friendly release team, Ned Deily @nad <https://discuss.python.org/u/nad> Steve Dower @steve.dower <https://discuss.python.org/u/steve.dower> Pablo Galindo Salgado @pablogsal <https://discuss.python.org/u/pablogsal> Łukasz Langa @ambv <https://discuss.python.org/u/ambv>

4 4