Mailman 3 June 2021 - Python-Dev

Delayed evaluation of f-strings?
by Eric Nieuwland June 25, 2021

June 25, 2021

In a recent discussion with a colleague we wondered if it would be possible to postpone the evaluation of an f-string so we could use it like a regular string and .format() or ‘%’. I found https://stackoverflow.com/questions/42497625/how-to-postpone-defer-the-eval… and tweaked it a bit to: import inspect class DelayedFString(str): def __str__(self): vars = inspect.currentframe().f_back.f_globals.copy() vars.update(inspect.currentframe().f_back.f_locals) return … [View More]

8 11

Towards removing asynchat, asyncore and smtpd from the stdlib
by Irit Katriel June 24, 2021

June 24, 2021

The asynchat [1] and asyncore [2] libraries have been deprecated since 3.6 in favor of asyncio [3]. In addition, smtpd [4], which depends on asynchat and asyncore, is deprecated in favor of aiosmtpd [5]. The documentation for each of these libraries mentions that it is deprecated and refers to the suggested replacement. However, they do not yet emit DeprecationWarnings at import, so people may be using them without being aware that they are no longer maintained (there are a few dozen open … [View More]

4 5

Making PY_SSIZE_T_CLEAN not mandatory.
by Inada Naoki June 22, 2021

June 22, 2021

Hi, folks, Since Python 3.8, PyArg_Parse*() APIs and Py_BuildValue() APIs emitted DeprecationWarning when '#' format is used without PY_SSIZE_T_CLEAN defined. In Python 3.10, they raise a RuntimeError, not a warning. Extension modules can not use '#' format with int. So how about making PY_SSIZE_T_CLEAN not mandatory in Python 3.11? Extension modules can use '#' format with ssize_t, without PY_SSIZE_T_CLEAN defined. Or should we wait one more version? Regards, -- Inada Naoki <songofacandy(a)gmail.com>

11 25

April Steering Council update
by Pablo Galindo Salgado June 21, 2021

June 21, 2021

Hi everyone, The SC has just published the community update for April: https://github.com/python/steering-council/blob/main/updates /2021-04-steering-council-update.md As a reminder, we'll are trying to keep this up monthly. As you can see we are mainly focusing on clearing the PEP backlog and addressing ongoing efforts and time-sensitive issues. We have currently a very packed agenda and we are doing our best to get to it as fast as we can, prioritizing what's necessary (as bootstrapping … [View More]the developer in residence position). Thanks a lot for your patience and understanding meanwhile we get to review your PEP or request :) If you have any request or concern, you can open an issue in the SC repo: https://github.com/python/steering-council Here is the text for the update (with links): *April 5* - The Steering Council discussed PEP 647: User-Defined Type Guards <https://www.python.org/dev/peps/pep-0647/> and approved it. An acceptance notice was sent. It was discussed that after Python 3.10, the Steering Council should start a larger discussion around the typing language and how it relates to the Python language. - The Steering Council discussed PEP 654: Exception Groups and except* <https://www.python.org/dev/peps/pep-0654/> and it was decided that some members needed more time to review some of the existing discussion as well as Nathaniel's feedback. - The Steering Council will inform the community around expectations for scheduling. No new features (unless straight forward) will be approved after the beta freeze. - The Steering Council discussed accepting the clarification around PyPA members being PEP sponsors. The commit with the proposal was merged and the issue was closed. - The group discussed a response to Debian following the ongoing discussion around the future of the Python package in the Debian distribution and it was decided that Pablo would send the email to the Debian group. *April 12* - The Steering Council discussed at length PEP 654: Exception Groups and except* <https://www.python.org/dev/peps/pep-0654/>. The group decided an email should be sent to python-dev@ asking for more discussion and Thomas would draft that email. - The group worked on the PyCon US 2021 Steering Council keynote - Pablo mentioned he would send out the email to the Debian folks soon (which was sent April 13). *April 19* - The Steering Council discussed PEP 646: Variadic Generics <https://www.python.org/dev/peps/pep-0646/> and was decided that a decision will be postponed to after Python 3.10 as there was not enough time to properly evaluate the PEP given the other, more time pressing issues regarding PEP 649: Deferred Evaluation Of Annotations Using Descriptors <https://www.python.org/dev/peps/pep-0649/> and type annotations. - The group discussed at length some concerns raised by a group of users and library authors regarding that the current release of 3.10 is going to make life very difficult to “pydantic”, users of the library and similar libraries that use type annotations at runtime. This is due to some limitations in PEP 563: Postponed Evaluation of Annotations <https://www.python.org/dev/peps/pep-0563/> that affect users of runtime annotations (and is also related with PEP 649: Deferred Evaluation Of Annotations Using Descriptors <https://www.python.org/dev/peps/pep-0649/>). The Steering Council discussed at length different possibilities with a careful evaluation of costs, risks and work to be done and decided that we simply can’t risk the compatibility breakage of PEP 563. The group decided that for stringified annotations the default must be reverted, at least for Python 3.10. Thomas will send an email to python-dev with the decision. *April 26* - The Steering Council discussed PEP 654: Exception Groups and except* <https://www.python.org/dev/peps/pep-0654/>., deciding to postpone the PEP to 3.11, and postpone their decision for 3.11 until after the Language Summit. - The SC discussed PEP 648: Extensible customizations of the interpreter at startup <https://www.python.org/dev/peps/pep-0648/>, deciding to postpone it to 3.11. - The SC reviewed PEP 467: Minor API improvements for binary sequences <https://www.python.org/dev/peps/pep-0467/>, which was postponed to 3.11 by its author. - The SC planned for the PyCon US keynote and Q&A, which will be recorded next week. - The SC briefly discussed the notion of adding sponsor logos to docs.python.org. - The SC discussed the proposal to delegate typing PEPs to a typing WG or BDFL, but deferred further discussion until later. - The SC discussed the role of CODEOWNERS in CPython and how different core devs use the file, and the consensus was that setting expectations for both reviewers and PR authors could be beneficial and could help to avoid misunderstandings. It was decided that some devguide changes could be proposed. Regards from rainy London. Pablo Galindo Salgado [View Less]

1 0

[RELEASE] Python 3.10.0b3 is available
by Pablo Galindo Salgado June 21, 2021

June 21, 2021

Summer is almost here (at least in half of the planet) and Python 3.10 is finishing baking in the oven. For those of you that want to taste it before is finally ready (and if you are a library developer, you certainly do!) you can have the second-to-last beta now, but be careful as is still very hot ;) https://www.python.org/downloads/release/python-3100b3/ #This is a beta preview of Python 3.10 Python 3.10 is still in development. 3.10.0b3 is the third of four planned beta release previews. … [View More]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 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 to 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 of Python 3.10 will be 3.10.0b4, currently scheduled for Saturday, 2021-07-10. #And now for something completely different There are no green stars. Why? In general, objects don’t emit a single wavelength of light when they shine. Instead, they emit photons in a range of wavelengths. If you were to use some sort of detector that is sensitive to the wavelengths of light emitted by an object, and then plotted the number of them versus wavelength, you get a lopsided plot called a blackbody curve. For an object as hot as the Sun, that curve peaks at blue-green, so it emits most of its photons there. But it still emits some that are bluer, and some that are redder. When we look at the Sun, we see all these colors blended together. Our eyes mix them up to produce one color: white. A warmer star will put out more blue, and a cooler one redder, but no matter what, our eyes just won’t see that as green. Due to how we perceive color, the only way to see a star as being green is for it to be only emitting green light. But as starts always emit radiation following the blackbody curve, that’s pretty much impossible. # We hope you enjoy those 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. Regards from very cloudy London, Your friendly release team, Pablo Galindo @pablogsal Ned Deily @nad Steve Dower @steve.dower [View Less]

2 1

Summary of Python tracker Issues
by Python tracker June 18, 2021

June 18, 2021

ACTIVITY SUMMARY (2021-06-11 - 2021-06-18) 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 7446 (-11) closed 48743 (+67) total 56189 (+56) Open issues with patches: 2962 Issues opened (41) ================== #41611: IDLE: problems with completions on Mac https://bugs.python.org/issue41611 reopened by terry.reedy #43475: Worst-case behaviour of … [View More]

1 0

Summary of Python tracker Issues
by Python tracker June 11, 2021

June 11, 2021

ACTIVITY SUMMARY (2021-06-04 - 2021-06-11) 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 7457 (+31) closed 48676 (+53) total 56133 (+84) Open issues with patches: 2955 Issues opened (60) ================== #11105: Compiling recursive Python ASTs crash the interpreter https://bugs.python.org/issue11105 reopened by BTaskaya #44242: enum.IntFlag … [View More]

1 0

[RELEASE] Python 3.8.10, 3.9.5, and 3.10.0b1 are now available
by Łukasz Langa June 11, 2021

June 11, 2021

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 … [View More]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> [View Less]

4 4

New pythoncapi_compat project adding Python 3.10 support to your C extensions without losing Python 2.7-3.9 support
by Victor Stinner June 8, 2021

June 8, 2021

Hi, What do you think of promoting the pythoncapi_compat project that I'm introducing below in the "C API: Porting to Python 3.10" section of What's New In Python 3.10? Should this project be moved under the GitHub psf organization to have a more "future proof" URL? I would like to promote this project to prepare C extensions maintainers for the following incompatible C API change (Py_TYPE) that I would like to push into Python 3.11: https://github.com/python/cpython/pull/26493 (Py_REFCNT … [View More]was already converted to a static inline function in Python 3.10.) I already made this Py_TYPE change in Python 3.10, but I had to revert it since it broke too many projects. Since last year, I upgraded most of these broken projects, I created the pythoncapi_compat project, and I succeeded to use upgrade_pythoncapi.py script and copy the pythoncapi_compat.h header file in multiple C extensions. C extensions written with Cython are not affected. I already fixed Cython last year to emit code compatible with my incoming incompatible change. If it's not done yet, you only have to regenerate the C files using a recent Cython version. -- I wrote a new script which adds Python 3.10 support to your C extensions without losing Python 2.7 support: https://github.com/pythoncapi/pythoncapi_compat To add Python 3.10 support to your C extension, go to its source directory and run: /path/to/upgrade_pythoncapi.py . It upgrades all C files (.c) in the current directory and subdirectories. For example, it replaces "op->ob_type" with "Py_TYPE(op)". It creates an ".old" copy of patched files. Use the -o option to select operations: * -o Py_TYPE: only replace "obj->ob_type" with "Py_TYPE(obj)". * -o all,-PyMem_MALLOC: run all operations, but don't replace PyMem_MALLOC(...) with PyMem_Malloc(...). -- The upgrade_pythoncapi.py script relies on the pythoncapi_compat.h header file that I wrote to provide recent Python 3.9-3.11 C functions on old Python versions. Examples: Py_NewRef() and PyThreadState_GetFrame(). Functions are implemented as simple static inline functions to avoid requiring to link your extension to a dynamic library. You can already use the new Py_NewRef() and Py_IsNone() Python 3.10 functions in your projects without losing support for Python 2.7-3.9! -- The script also replaces "frame->f_back" with "_PyFrame_GetBackBorrow(frame)". The _PyFrame_GetBackBorrow() function doesn't exist in the Python C API, it's only provided by pythoncapi_compat.h to ease the migration of C extensions. I advise you to replace _PyFrame_GetBackBorrow() (borrowed reference) with PyFrame_GetBack() (strong reference). -- This project is related to my PEP 620 "Hide implementation details from the C API" which tries to make the C API more abstract to later allow to implement new optimization in CPython and to make other Python implementations like PyPy faster when running C extensions. Article on the creation of the pythoncapi project: https://vstinner.github.io/pythoncapi_compat.html The main drawback of this project is that it uses regular expressions to parse C code. Such "parser" can miss C code which has to be patched manually. In my experience, additional manual changes are really rare and take less than 1 minute on a very large C extension like numpy. -- This project only targets extension modules written in C by using directly the "Python.h" API. I advise you to use Cython or HPy to no longer be bothered with incompatible C API changes at every Python release ;-) * https://cython.org/ * https://hpy.readthedocs.io/ I hope that my script will facilitate migration of C extensions to HPy. Victor -- Night gathers, and now my watch begins. It shall not end until my death. [View Less]

4 4

Re: name for new Enum decorator
by Irit Katriel June 8, 2021

June 8, 2021

> On 6 Jun 2021, at 16:58, Andrei Kulakov <andrei.avk(a)gmail.com> wrote: > > > In Math / CompSci there is a definition that almost exactly matches this: Exact Cover - https://en.wikipedia.org/wiki/Exact_cover > > The difference is that, IIRC, solving the problem is finding and removing all subsets that are unneeded to create an exact cover, so it's kind of arriving at it from a different direction, but 'exact cover' definition itself is a good match. I’m not sure it’… [View More]

4 4