Mailman 3 August 2021 - Python-Dev

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

PEP 467 feedback from the Steering Council
by Barry Warsaw 12 Sep '21

12 Sep '21

Hello Nick, Ethan, The Python Steering Council reviewed PEP 467 -- Minor API improvements for binary sequences at our 2021-07-26 meeting. Thank you for work on this PEP. We’re generally very favorable for adding to Python 3.11 the features and APIs described in the PEP. We have some requests for changes that we’d like you to consider. * The Python-Version in the PEP needs to target Python 3.11 of course. * We think it would be better if bytes.fromsize()’s second argument was a keyword-enabled or keyword-only argument. We understand the rationale given in the PEP for not doing so, but ultimately we think the readability of (at least allowing) a keyword argument to be more compelling. Some possible options include `fill`, `value`, or `byte`. * We all really dislike the word “ord” as in `bytes.fromord()`. We understand the symmetry of this choice, but we also feel like we have an opportunity to make it more understandable, so we recommend `bytes.fromint()` and `bytearray.fromint()`. * We think the `bchr()` built-in is not necessary. Given the `.fromint()` methods, it’s better not to duplicate the functionality, and everything has a cost. A built-in that exists only for the symmetry described in the PEP is just a little extra complexity for little value. Let us know what you think about making these changes. We aren’t making acceptance contingent on these changes, but we do think they make the PEP and the new APIs better. -Barry (on behalf of the Python Steering Council)

21 57

Discrepancy between what aiter() and `async for` requires on purpose?
by Brett Cannon 08 Sep '21

08 Sep '21

If you look at https://github.com/python/cpython/blob/b11a951f16f0603d98de24fee5c023df83ea… you will see that `async for` requires that the iterator returned from `__aiter__` define `__anext__`. But if you look at aiter() which uses PyObject_GetAiter() from https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66f… and PyAiter_Check() from https://github.com/python/cpython/blob/f0a6fde8827d5d4f7a1c741ab1a8b206b66f… you will notice that aiter() requires `__anext__` *and* `__aiter__` on the async iterator that gets returned from __aiter__. Now the docs for aiter() at https://docs.python.org/3.10/library/functions.html#aiter points out that the async iterator is expected to define both methods as does the glossary definition for "asynchronous iterator" ( https://docs.python.org/3.8/glossary.html#term-asynchronous-iterator). So my question is whether the discrepancy between what `async for` expects and what `aiter()` expects on purpose? https://bugs.python.org/issue31861 was the issue for creating aiter() and I didn't notice a discussion of this difference. The key reason I'm asking is this does cause a deviation compared to the relationship between `for` and `iter()` (which does not require `__iter__` to be defined on the iterator, although collections.abc.Iterator does). It also makes the glossary definition being linked from https://docs.python.org/3.10/reference/compound_stmts.html#the-async-for-st… incorrect.

7 9

Making code object APIs unstable
by Guido van Rossum 07 Sep '21

07 Sep '21

In 3.11 we're changing a lot of details about code objects. Part of this is the "Faster CPython" work, part of it is other things (e.g. PEP 657 -- Fine Grained Error Locations in Tracebacks). As a result, the set of fields of the code object is changing. This is fine, the structure is part of the internal API anyway. But there's a problem with two public API functions, PyCode_New() and PyCode_NewWithPosArgs(). As we have them in the main (3.11) branch, their signatures are incompatible with previous versions, and they have to be since the set of values needed to create a code object is different. (The types.CodeType constructor signature is also changed, and so is its replace() method, but these aren't part of any stable API). Unfortunately, PyCode_New() and PyCode_NewWithPosArgs() are part of the PEP 387 stable ABI. What should we do? A. We could deprecate them, keep (restore) their old signatures, and create crippled code objects (no exception table, no endline/column tables, qualname defaults to name). B. We could deprecate them, restore the old signatures, and always raise an error when they are called. C. We could just delete them. D. We could keep them, with modified signatures, and to heck with ABI compatibility for these two. E. We could get rid of PyCode_NewWithPosArgs(), update PyCode() to add the posonlyargcount (which is the only difference between the two), and d*mn the torpedoes. F. Like (E), but keep PyCode_NewWithPosArgs() as an alias for PyCode_New() (and deprecate it). If these weren't part of the stable ABI, I'd choose (E). But because they are, I think only (A) or (B) are our options. The problem with (C) is that if there's code that links to them but doesn't call them (except in some corner case that the user can avoid), the code won't link even though it would work fine. The problem with (D) is that if it *is* called by code expecting the old signature it will segfault. I'm not keen on (A) since it can cause broken code objects when used to copy a code object with some modified metadata (e.g. a different filename), since there's no way to pass the exception table (and several other fields, but the exception table is an integral part of the code now). Code wanting to make slight modifications to code objects such as changing co_name or co_filename should switch to the .replace() API, which is much better at this (though calling it from C is a pain, it's possible). Code wanting to synthesize code should be updated for each release; we should probably require such code to be built with the internal API and use _PyCode_New(), which takes a struct argument containing all the necessary fields. Thoughts? I'm especially interested in Petr's opinion given that this is a case where we'd like to deprecate something in the stable ABI. See also discussion in https://bugs.python.org/issue40222 (esp. near the end). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>

16 36

API's to interface python with Eclipse to execute and debug C/C++ Source files.
by Chandrakant Shrimantrao 04 Sep '21

04 Sep '21

Hi, We would like to know if there is any option available to execute and debug( setting break point and delete break point) C/C++ Source files Python API's inside Eclipse IDE after interfacing Pydev with Eclipse. Please let us know. Thanks and regards. Chandrakant shrimantrao. L&T Technology Services Ltd www.LTTS.com L&T Technology Services Limited (LTTS) is committed to safeguard your data privacy. For more information to view our commitment towards data privacy under GDPR, please visit the privacy policy on our website www.Ltts.com. This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system.

3 2

Is anyone relying on new-bugs-announce/python-bugs-list/bugs.python.org summaries
by Ammar Askar 03 Sep '21

03 Sep '21

Hey everyone, As part of PEP 588, migrating bugs.python.org issues to Github, there are two current mailing list related items that need a replacement or need to be turned down. 1. Weekly summary emails with bug counts and issues from the week, example: https://mail.python.org/archives/list/python-dev@python.org/thread/JRFJ4QH7… 2. Emails sent to the new-bugs-announce and python-bugs-list for new issues and comments to existing issues. I wanted to quickly gauge if anyone is relying on these mailing lists/emails or if it's a convenient part of your workflow. Feel free to chime in here or on the migration issues directly with your use-case: 1. https://github.com/psf/gh-migration/issues/6 2. https://github.com/psf/gh-migration/issues/7 Thanks, Ammar

7 6

Python-Dev August 2021