[Python-Dev] PEP 701 – Syntactic formalization of f-strings

Hi everyone, I am very excited to share with you a PEP that Batuhan Taskaya, Lysandros Nikolaou and myself have been working on recently: PEP 701 - PEP 701 – Syntactic formalization of f-strings . We believe this will be a great improvement in both the

[Python-Dev] PEP 699: Remove private dict version field added in PEP 509

I've created a new PEP to repeal PEP 509. Please post comments to the Discourse thread. Thank you! Discourse thread: https://discuss.python.org/t/pep-699-remove-private-dict-version-field-added-in-pep-509/19724 Link to the PEP: https://github.com/python/peps/blob/main/pep-0699.rst

[Python-Dev] PEP 690: Lazy Imports

Hello, PEP 690 is now live! It proposes an exciting new feature to transparently defer the execution of imported modules until the moment when an imported object is used. Since Python programs commonly import many more modules than a single invocation of the

[Python-Dev] PEP 689 – Semi-stable C API tier

Hello, Victor and others are organizing the C-API to make it clearer what's public and what's private (see Victor's file-based stats: https://pythoncapi.readthedocs.io/stats.html) It became clear that we need a tier between public and private C-API. PEP 689 proposes such API, with an opt-in

[Python-Dev] PEP 687 – Isolating modules in the standard library

Hello, Please provide any feedback you might have on PEP 687 – Isolating modules in the standard library: https://peps.python.org/pep-0687/ From recent discussions around “what should have a PEP”, it’s clear that this should have been a PEP long ago. Better late than never, I guess! We

[Python-Dev] PEP 686 – Make UTF-8 mode default

Hi, all. I wrote a new PEP last month. I'm sorry that I forgot to announce it here. The pep is here: https://peps.python.org/pep-0686/ Discussions: * https://discuss.python.org/t/14737 (current thread) * https://discuss.python.org/t/14435 (previous thread) -- Inada Naoki

[Python-Dev] PEP 684: A Per-Interpreter GIL

I'd really appreciate feedback on this new PEP about making the GIL per-interpreter. The PEP targets 3.11, but we'll see if that is too close. I don't mind waiting one more release, though I'd prefer 3.11 (obviously). Regardless, I have no intention of rushing this through at the expense of

[Python-Dev] PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 3)

I've updated PEP 683 for the feedback I've gotten. Thanks again for that! The updated PEP text is included below. The largest changes involve either the focus of the PEP (internal mechanism to mark objects immortal) or the possible ways that things can break on older 32-bit stable ABI

[Python-Dev] PEP 683: "Immortal Objects, Using a Fixed Refcount" (round 2)

Thanks to all those that provided feedback. I've worked to substantially update the PEP in response. The text is included below. Further feedback is appreciated. -eric PEP: 683 Title: Immortal Objects, Using a Fixed Refcount Author: Eric Snow , Eddie Elizondo

[Python-Dev] PEP 683: "Immortal Objects, Using a Fixed Refcount"

Eddie and I would appreciate your feedback on this proposal to support treating some objects as "immortal". The fundamental characteristic of the approach is that we would provide stronger guarantees about immutability for some objects. A few things to note: * this is essentially an

[Python-Dev] PEP 682: Format Specifier for Signed Zero

Just a note that this PEP is being discussed at https://discuss.python.org/t/pep-682-format-specifier-for-signed-zero TLDR; When formatting a number (especially with rounding options), often you don't want negative-signed zero as an output. A format spec extension enables normalizing such

[Python-Dev] PEP 677 (Callable Type Syntax): Rejection notice.

Thank you PEP authors for producing a very well written and laid out PEP. That made it easy to understand the proposal, rationale, and alternatives considered. We agree that the existing typing.Callable syntax, while capable, is less than ideal for humans. That said, we deliberated last week and

[Python-Dev] PEP-657 and co_positions (was: Please update Cython *before* introcuding C API incompatible changes in Python)

Pablo Galindo Salgado schrieb am 09.02.22 um 17:40: Should there be a getter/setter for co_positions? We consider the representation of co_postions private Yes, and that's the issue. so we don't want (for now) to ad getters/setters. If you want to get the position of a instruction, you

[Python-Dev] PEP 678: Enriching Exceptions with Notes

Hi all, I've written PEP 678, proposing the addition of a __note__ attribute which can be used to enrich displayed exceptions. This is particularly useful with ExceptionGroup, or where exception chaining is unsuitable, and ensures that 'orphan' output is not produced if the annotated exception

[Python-Dev] PEP 674 – Disallow using macros as l-value (version 2)

Hi, I made the following changes to the PEP since the version 1 (November 30): * Elaborate the HPy section and add a new "Relationship with the HPy project" section * Elaborate which projects are impacted and which changes are needed * Remove the PyPy section The PEP can be read online:

[Python-Dev] PEP 677 (Callable Type Syntax): Final Call for Comments

Hello all, We’d like to make a last call for discussion on PEP 677: Callable Type Syntax [1] before sending this to the Steering Council. For context, PEP 677 proposes an arrow-like callable syntax for python: ``` (int, str) -> bool # equivalent to Callable[[int, str], bool] ``` Thanks

[Python-Dev] PEP 676 -- PEP Infrastructure Process

Hi, I would like to announce PEP 676 to python-dev. It is a meta-PEP focussed on modernising the PEP build infrastructure. From the abstract, "This PEP addresses the infrastructure around rendering PEP files from reStructuredText files to HTML webpages. We aim to specify a self-contained and

[Python-Dev] PEP 679 – Allow parentheses in assert statements

Hi everyone, I would like to start a discussion about a small PEP proposal to allow parentheses in assert statements to fix a common gotcha with assert statements. Link to the PEP: https://www.python.org/dev/peps/pep-0679/ *Please, redirect all discussions to: *

[Python-Dev] PEP 669: Low Impact Monitoring for CPython

Hi, I would like to announce latest PEP, PEP 669: Low Impact Monitoring for CPython. The aim of this PEP is to provide an API for profilers, debuggers and other tools to avoid the punitive overhead of using sys.settrace. If you have any interest in profilers, debuggers, coverage tools or

[Python-Dev] PEP template file now available

I just pushed an update to PEP 12 which includes a complete PEP template file. You can see the file at https://github.com/python/peps/blob/main/pep-0012/pep-.rst and it is also embedded in PEP 12 at https://python.github.io/peps/pep-0012/#template (it will hit the official URL eventually).

[Python-Dev] PEP 674: Disallow using macros as l-value

Hi, I propose to disallow using macros as l-value. Read and comment the plain text below, or read the PEP 674 online, https://python.github.io/peps/pep-0674/ While I'm not sure that the proposed changes are really controversial, I decided to write a formal PEP since the incompatible changes are

[Python-Dev] PEP 467: Minor bytes and bytearray improvements

The final PEP with SC feedback incorporated and one last addition: `bytes.ascii` as a replacement for the Python 2 idiom of `str(some_var)` to get the bytes version, and the Python 3 workaround of either the correct `str(some_var).encode('astii') or the potentially wrong

[Python-Dev] PEP 663:

See the latest changes, which are mostly a (hopefully) improved abstract, better tables, and some slight rewordings. Feedback welcome! --- PEP: 663 Title: Standardizing Enum str(), repr(), and format() behaviors Version: $Revision$ Last-Modified: $Date$ Author:

[Python-Dev] PEP 3118 C APIs

Last year I opened the following issues, to implement int PyObject_CopyToObject() and PyObject *PyObject_GetMemoryView(PyObject *obj). They were meant to be as part of PEP 3118, I wonder if they are worth an effort now. https://bugs.python.org/issue39835 https://bugs.python.org/issue39836

[Python-Dev] PEP 670: Convert macros to functions in the Python C API

Hi, Erlend and me wrote a PEP to move away from macros in the Python C API. We are now waiting for feedback :-) Read the PEP online: https://www.python.org/dev/peps/pep-0670/ There is a copy of the PEP below for inline replies. Victor --- PEP: 670 Title: Convert macros to functions in the

[Python-Dev] PEP 505 (None-aware operators) for Python 3.11

Hello, I've been following PEP 505 (https://www.python.org/dev/peps/pep-0505/) since it was first proposed for Python 3.8. It's been deferred for some time and I'm interested in seeing it in Python 3.11, but I know there were also a number of objections which resulted in it being deferred

[Python-Dev] PEP 654 except* formatting

We wonder if people have a view on which of the following is clearer/better: 1. except *E as e: // except *(E1, E2) as e: 2. except* E as e: // except* (E1, E2) as e: (The difference is in the whitespace around the *). At the moment * is a separate token so both are allowed, but we could

[Python-Dev] PEP: Taking the Python C API to the Next Level

Hi, I would like to change the Python C API. I failed to write a single document listing all constraints and proposing all changes that I would to do. For example, my previous PEP 620 contains too many changes and is too long. Here is my attempt to focus on the bare minimum and (what I consider

[Python-Dev] PEP-646 question: unpacking into single Generic parameter

Hello, first of all, thanks for working on variadic generics! I look forward to them. My question: all the examples in https://www.python.org/dev/peps/pep-0646/ unpack into variadic arguments. But can I write code like this? ``` Ts = TypeVarTuple("Ts") def enumerate_args(f:

[Python-Dev] PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors

PEP 663 is presented below for your viewing pleasure. Comments, questions, and concerns are welcome. PEP: 663 Title: Improving and Standardizing Enum str(), repr(), and format() behaviors Version: $Revision$

[Python-Dev] PEP-535 (Rich comparison chaining) Discussion?

Hi all, PEP 535 was deferred until Python 3.8. I would like to discuss the PEP given that some time has passed, and I _personally_ would benefit from its acceptance. ## A little about me: As a reasonably long-time Python user (well, 16 years), I have gradually moved from using only the core

[Python-Dev] PEP 667: Consistent views of namespaces

Hi all, I have submitted PEP 667 as an alternative to PEP 558. https://www.python.org/dev/peps/pep-0667/ Nick and I have agreed to disagree on the way to fix locals() and f_locals. We are both in agreement that it needs fixing. In summary, PEP 667 has roughly the same surface behavior as PEP

[Python-Dev] PEP 649: Deferred Evaluation Of Annotations

I'd like to revive the discussion of PEP 649 [https://www.python.org/dev/peps/pep-0649/] that started shortly before development of 3.10 features was closed. This is Larry's PEP to defer evaluation of __annotations__ until it's actually accessed. During the discussion the decision was made to

[Python-Dev] PEP 467 feedback from the Steering Council

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

[Python-Dev] PEP 558, the simplest thing I could come up with

Hi Nick, Our discussion on PEP 558 got me thinking "What is the simplest thing that would work?". This is what I came up (in the form of a draft PEP): https://github.com/markshannon/peps/blob/pep-locals/pep-06xx.rst It doesn't have O(1) len(f_locals), and it does break `PyEval_GetLocals()`

[Python-Dev] PEP 558: Defined semantics for locals()

Hi folks, It's been a long time coming, but I've finally made enough progress on the reference implementation that I think it's time to ask Nathaniel to pronounce on the current iteration of PEP 558 (Defined semantics for locals()). The rendered version is up at

[Python-Dev] PEP 657 Accepted - Include Fine Grained Error Locations in Tracebacks

I’m happy to announce that PEP 657 (Include Fine Grained Error Locations in Tracebacks) has been unanimously accepted for Python 3.11 by the Python Steering Council. Congratulations Pablo, Batuhan, and Ammar! Cheers, -Barry (on behalf of the Steering Council) signature.asc Description:

[Python-Dev] PEP 661: Sentinel Values

Hi, I have prepared a PEP proposing adding a stdlib function for defining sentinel values. You can find the PEP here: https://www.python.org/dev/peps/pep-0661/ The discussion is happening in the discourse server: https://discuss.python.org/t/pep-661-sentinel-values/9126 To avoid splitting the

[Python-Dev] PEP 659: Specializing Adaptive Interpreter

Hi everyone, I would like to present PEP 659. This is an informational PEP about a key part of our plan to improve CPython performance for 3.11 and beyond. For those of you aware of the recent releases of Cinder and Pyston, PEP 659 might look similar. It is similar, but I believe PEP 659

[Python-Dev] PEP 657 – Include Fine Grained Error Locations in Tracebacks

Hi, We have prepared a PEP with our proposal for fine-grained error locations in tracebacks. You can find the PEP here: https://www.python.org/dev/peps/pep-0657/ The discussion is happening in the discourse server:

[Python-Dev] PEP 652: Python 3.10 will have explicit Limited C API & Stable ABI

Hello, I've merged the main part of PEP-652 implementation. The Limited C API (introduced in PEP 384 and used for extension modules that work across Python versions without recompilation) is now explicitly defined and better tested. When changing/extending the limited API: - Stop and think!

[Python-Dev] PEP 563 and Python 3.10.

(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

[Python-Dev] PEP 563 and 649: The Great Compromise

The heart of the debate between PEPs 563 and 649 is the question: what should an annotation be?  Should it be a string or a Python value?  It seems people who are pro-PEP 563 want it to be a string, and people who are pro-PEP 649 want it to be a value. Actually, let me amend that slightly. 

[Python-Dev] PEP 563 in light of PEP 649

Hi all, I got pinged to voice my opinion on PEP 649 as the instigator of PEP 563. I'm sorry, this is long, and a separate thread, because it deals with three things: - Goals set for PEP 563 and how it did in practice; - PEP 649 and how it addresses those same goals; - can we cleanly adopt PEP

[Python-Dev] PEP-0467: Minor API improvements for binary sequences

Looking for final comments before submitting for SC approval. It would be nice to finally get this resolved. :) Full text follows. --- PEP: 467 Title: Minor API improvements for binary sequences Version: $Revision$

[Python-Dev] PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Attached is my second draft of PEP 649.  The PEP and the prototype have both seen a marked improvement since round 1 in January; PEP 649 now allows annotations to refer to any variable they could see under stock semantics: * Local variables in the current function scope or in enclosing

[Python-Dev] PEP 647 Accepted

The Python Steering Council reviewed PEP 647 -- User-Defined Type Guards, and is happy to accept the PEP for Python 3.10. Congratulations Eric! We have one concern about the semantics of the PEP however. In a sense, the PEP subverts the meaning of the return type defined in the signature of

[Python-Dev] PEP 652 Accepted -- Maintaining the Stable ABI

Hi Petr, Thank you for submitting PEP 652 (Maintaining the Stable ABI). After evaluating the situation and discussing the PEP, the Steering Council is happy with the PEP and hereby accepts it. The Steering council thinks that this is a great step forward in order to have a clear definition of

[Python-Dev] PEP 644 Accepted -- Require OpenSSL 1.1.1 or newer

Hi Christian, Thank you for submitting PEP 644 (Require OpenSSL 1.1.1). After evaluating the situation and discussing the PEP, the Steering Council is happy with the PEP, and hereby accepts it. The SC is of the opinion that this change will make it considerable easier to maintain the extension

[Python-Dev] PEP-376 and PEP-427 interpretation

Forgive me if this isn't the correct venue for this question and I ask your help directing me to the correct place if it is not. In PEP-376 it states with respect to the valid hashes in a Wheel RECORD file: "The hash is either the empty string or the hash algorithm as named in

[Python-Dev] PEP 654: Exception Groups and except* [REPOST]

We would like to present for feedback a new version of PEP 654, which incorporates the feedback we received in the discussions so far: https://www.python.org/dev/peps/pep-0654/ The reference implementation has also been updated along with the PEP. The changes we made since the first post are: 1.

[Python-Dev] PEP 646 (Variadic Generics): final call for comments

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

[Python-Dev] PEP 651, Robust Stack Overflow Handling, Rejection notice

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

[Python-Dev] PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi all, We would like to request feedback on PEP 654 -- Exception Groups and except*. https://www.python.org/dev/peps/pep-0654/ It proposes language extensions that allow programs to raise and handle multiple unrelated exceptions simultaneously, motivated by the needs of asyncio and other

[Python-Dev] PEP 653: Precise Semantics for Pattern Matching

Hi everyone, I'd like to announce a new PEP. https://www.python.org/dev/peps/pep-0653/ It builds on PEP 634 (Structural Pattern Matching: Specification), adding: More precise semantics. A bit more customization for complex classes. Its also a bit more robust and should be faster (eventually).

[Python-Dev] PEP 597 bikeshedding: envvar / option name.

I am updating PEP 597 to include discussions in the thread. Before finishing the PEP, I need to decide the option name. I used PYTHONWARNDEFAULTENCODING (envvar name) / warn_default_encoding (-X option and sys.flags name) before, but it seems too long and hard to type, easy to misspell.

[Python-Dev] PEP 647 (type guards) -- final call for comments

I think we have reached consensus on PEP 647 in typing-sig. We have implementations for mypy and pyright, not sure about the rest. This PEP does not affect CPython directly except for the addition of one special item (TypeGuard) to typing.py -- it would be nice to get that in the 3.10 stdlib. I'm

[Python-Dev] PEP 563: get_type_hints should use closure when available

The discussion around PEP 649 got me thinking about what I believe is the largest downside to PEP 563: the inability to evaluate annotations created with closures. While this is in general unavoidable, if the type is ever referenced in an annotated function (including as an annotation) it should

[Python-Dev] PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

Hi all, I would like to request feedback by python-dev on the current implementation of PEP 637 - Support for indexing with keyword arguments. https://www.python.org/dev/peps/pep-0637/ The PEP is ready for SC submission and it has a prototype implementation ready, available here (note, not

[Python-Dev] PEP 597: Add optional EncodingWarning

Hi, all. I updated the PEP 597 yesterday. Please review it to move it forward. PEP: https://www.python.org/dev/peps/pep-0597/ Previous thread: https://discuss.python.org/t/3880 Main difference from the previous version: * Added new warning category; EncodingWarning * Added dedicated option to

[Python-Dev] PEP 651: Robust Overflow Handling, version 2

Hi, I've updated the PEP in light of my experiments and feedback. The new API is simpler and a bit more backwards compatible. https://www.python.org/dev/peps/pep-0651/ Cheers, Mark. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe

[Python-Dev] PEP 651 -- Robust Overflow Handling

Hi everyone, It's time for yet another PEP :) Fortunately, this one is a small one that doesn't change much. It's aim is to make the VM more robust. Abstract This PEP proposes that machine stack overflow is treated differently from runaway recursion. This would allow programs to set

[Python-Dev] PEP: Deferred Evaluation Of Annotations Using Descriptors

I've written a new PEP.  Please find it below.  Happy reading! //arry/ -- PEP: Title: Deferred Evaluation Of Annotations Using Descriptors Version: $Revision$ Last-Modified: $Date$ Author: Larry Hastings Discussions-To: Python-Dev Status: Draft Type: Standards Track

[Python-Dev] PEP 642 v3: Explicit patterns for structured pattern matching

I’ve made a final round of updates to PEP 642 and submitted it to the Steering Council for consideration alongside PEP 634. As usual, the rendered version can be found here: https://www.python.org/dev/peps/pep-0642/ There's a Discourse thread at

[Python-Dev] PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Is there a bestiary of examples for the current pattern matching proposal(s)? It seems I don't have a good handle on how one matches simple tests like callability, function signatures, possession of specific attribute(s).etc. Also will matching ever extend into the Typing universe? --

[Python-Dev] PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hi folks, I have updated PEP 642 significantly based on the feedback received over the past week. Since the Discourse thread hadn't received any comments on it, I amended the existing thread in place rather than making a new one:

[Python-Dev] PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Hi folks, This is a mailing list repost of the Discourse thread at https://discuss.python.org/t/pep-642-constraint-pattern-syntax-for-structural-pattern-matching/5614 The rendered version of the PEP can be found here: https://www.python.org/dev/peps/pep-0642/ The full text is also quoted in the

[Python-Dev] PEP 640: Unused variable syntax.

One of the problems I have with the Pattern Matching proposal (PEP 622 originally, now PEPs 634, 635, 636) is the special-casing of '_' to not actually assign to the name, which is a subtle but meaningful divergence from the rest of Python. In discussions with the authors I proposed using '?'

[Python-Dev] PEP 11: Drop support for AIX releases without dlopen

Python has supported using dynload_shlib (using dlopen) on AIX since https://github.com/python/cpython/commit/c19c5a62aef7dce0e8147655b0d2f087965fae75 in 2003. This is also about the time that AIX 4.3 went out of support, which is believed to be the AIX release that added support for dlopen.

[Python-Dev] PEP 617 -- New PEG parser for CPython

I have access to a small Amazon Web Services credit through the end of November 2020. I'd be happy to let your team use that credit in support of the fuzzing validation mentioned below. "(One area we have not explored extensively is rejection of all wrong programs. We have unit tests that check

[Python-Dev] PEP 638: Syntactic macros

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 ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to

[Python-Dev] PEP 622: Arrow for capture patterns

Hi everyone, Sorry if this was proposed already. I looked here https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern, search for "idea to make lookup semantics the default". I saw that a few symbols like $ and ? were proposed, and I thought that maybe the annotation

[Python-Dev] PEP 632: Deprecate distutils module

Hi all. setuptools has recently adopted the entire codebase of the distutils module, so that they will be able to make improvements directly without having to rely on patching the standard library. As a result, we can now move forward with official deprecation (in 3.10) and removal (in 3.12)

[Python-Dev] PEP 622 and Walrus operator

I'm intrigued by PEP 622. It sounds like a great addition, as the current PEP mentions, the lack of being able to match against a local variable seems like a great limitation. I'll admit to being over my head here; last time I did language design was undergrad CS 15 years ago. However, I was

[Python-Dev] PEP 515: Non-empty return statement

Per PEP 515: > It is a SyntaxError to have a non-empty return statement in an > asynchronous generator. Synchronus generators can return values that include it in the StopIteration exception. Why would a return value in an asynchronous generator not do the same in the StopAsyncIteration?

[Python-Dev] PEP 622 questions

Hi there, As a poor user, I am extremely excited about the possibilities PEP 622 (structural pattern matching) opens. I'd like to ask a few questions. I hope these were not already answered in other threads, which it is hard to follow given the amounts of information. First, I'd like to know

[Python-Dev] PEP 622 (Structural Pattern Matching) questions

Hi, I have two questions about PEP 622, as it stands. 1. Is the current version the final version? 2. Is the difference in semantics between the Django example and the proposed replacement deliberate or accidental? (The difference being the change in behaviour for sequences other than list

[Python-Dev] PEP 622: Structural Pattern Matching -- followup

On 24/06/2020 20:38, Guido van Rossum wrote: > Everyone, > > If you've commented and you're worried you haven't been heard, please=20 > add your issue *concisely* to this new thread. Note that the following=20 > issues are already open and will be responded to separately; please=20 > don't bother

[Python-Dev] PEP 622: Structural Pattern Matching -- followup

> On 25 Jul 2020, at 03:44, Rob Cliffe wrote: > > Without arguing for or against allowing a capture variable, IMO rather > than syntax like >match into : > it would be far better (and not require a new keyword) to write this as >with as match : > > On 24/06/2020 20:38, Guido van

[Python-Dev] PEP 622 aspects

PEP 622 authors, Overall, the PEP describes the proposal quite nicely. However, I do indeed have concerns and questions, some of which I describe in this email. (1) Class pattern that does isinstance and nothing else. If I understand the proposed semantics correctly, `Class()` is equivalent to

[Python-Dev] PEP 622: capturing into an explicit namespace

Hi Python-dev and PEP 622 Authors, I saw this idea, or something like it, posted by a couple of people, but didn't see much discussion of it, and skimming the PEP today, I didn't see a mention of it. Maybe I just missed it; my apologies if so, and a link to the relevant discussion/text would be

[Python-Dev] PEP 626: Precise line numbers for debugging and other tools.

Hi all, I'd like to announce a new PEP. It is mainly codifying that Python should do what you probably already thought it did :) Should be uncontroversial, but all comments are welcome. Cheers, Mark. ___ Python-Dev mailing list --

[Python-Dev] PEP 622 idea: "match case object" to represent match patterns

Recent discussion on the store vs. load syntax issues of PEP 622 prompted a (yet unripe) idea that could hopefully spur some progress. What if cases required some sort of MatchCase (name pending) object which could be preconstructed by the user if needed, but also inferred on the fly if

[Python-Dev] PEP 622 and variadic positional-only args

I've taken a look through PEP 622 and I've been thinking about how it could be used with sympy. In principle case/match and destructuring should be useful for sympy because sympy has a class Basic which defines a common structure for ~1000 subclasses. There are a lot of places where it is

[Python-Dev] PEP 622 constant value syntax idea

Hi, I had an idea regarding the pattern matching issue of comparing with a previous constant variable instead of assigning to a new local variable. I'm not sure if this has been brought up before but instead of using a symbol with the case statement what if we used a keyword. So for example, x

[Python-Dev] PEP 622 and fitting the pieces together

Having followed this discussion for a while, I'm trying to put my finger on why I feal uneasy about it. The major features I see in this proposal are: * New syntax for trying multiple assignments until one matches. * Extending destructuring assignment to match constants in the LHS.

[Python-Dev] PEP 622 version 2 (Structural Pattern Matching)

Today I’m happy (and a little trepidatious) to announce the next version of PEP 622, Pattern Matching. As authors we welcome Daniel F Moisset in our midst. Daniel wrote a lot of the new text in this version, which introduces the subject matter much more gently than the first version did. He also

[Python-Dev] PEP 624: Remove Py_UNICODE encoder APIs

Hi, folks. Since the previous discussion was suspended without consensus, I wrote a new PEP for it. (Thank you Victor for reviewing it!) This PEP looks very similar to PEP 623 "Remove wstr from Unicode", but for encoder APIs, not for Unicode object APIs. URL (not available yet):

[Python-Dev] PEP 622 railroaded through?

Whoa! I have an uneasy feeling about this PEP. AFAIK the usual procedure for adding a new feature to Python is:     An idea is raised and attracts some support.     Someone sufficiently motivated writes a PEP.     The PEP is thoroughly discussed.     Eventually a consensus (or at least an

[Python-Dev] PEP 622 (match statement) playground

If you are interested in learning more about how PEP 622 would work in practice, but don't feel like compiling a Python 3.10 fork from source, here's good news for you. In a hurry? https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playground-622.ipynb This will open a Binder

[Python-Dev] PEP 622 pattern matching syntax

Hello Python Devs, For some time I've been hoping to be able to use pattern matching in Python, so PEP 622 is an exciting proposition. I do have some concerns, mostly about the syntax, because it doesn't currently match the style the rest of Python seems to lay out. The thing I'd most suggest

[Python-Dev] PEP 622: Structural Pattern Matching -- followup

Everyone, If you've commented and you're worried you haven't been heard, please add your issue *concisely* to this new thread. Note that the following issues are already open and will be responded to separately; please don't bother commenting on these until we've done so: - Alternative spellings

[Python-Dev] PEP 622: Structural Pattern Matching

I'm happy to present a new PEP for the python-dev community to review. This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin. Many people have thought about extending Python with a form of pattern matching similar to that found in Scala, Rust, F#, Haskell and other

[Python-Dev] (PEP 620) C API for efficient loop iterating on a sequence of PyObject** or other C types

Le mar. 23 juin 2020 à 03:47, Neil Schemenauer a écrit : > One final comment: I think even if we manage to cleanup the API and > make it friendly for other Python implementations, there is going to > be a fair amount of overhead. If you look at other "managed > runtimes" that just seems

[Python-Dev] PEP 620: Hide implementation details from the C API

Hi, PEP available at: https://www.python.org/dev/peps/pep-0620/ This PEP is the result of 4 years of research work on the C API: https://pythoncapi.readthedocs.io/ It's the third version. The first version (2017) proposed to add a "new C API" and advised C extensions maintainers to opt-in for

[Python-Dev] PEP 387: backwards compatibility policy

Started at a discussion at https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421 to try to finally resolve this PEP and our backwards compatibility policy. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an

[Python-Dev] PEP 584 underspecified

I know this is late in the cycle to think of this. But I just realized the PEP 584 does not say anything about order guarantees. I think it is safe to assume that existing keys in dictA will not have order modified by `dictA |= dictB`. However, the PEP does not state what order we are given

[Python-Dev] PEP 618: Add Optional Length-Checking To zip

I have pushed a second draft of PEP 618: https://www.python.org/dev/peps/pep-0618 Please let me know what you think – I'd love to hear any new feedback that hasn't yet been addressed in the PEP! Brandt ___ Python-Dev mailing list --

[Python-Dev] PEP 615 (zoneinfo) implementation ready for review

Hey all, The feature freeze is coming up on us fast, and the PEP 615 implementation is more or less ready to be integrated into the standard library (may need one or two little tweaks, but it's well past the "minimum viable product" stage). Normally I'd wait longer for someone to volunteer for

[Python-Dev] PEP 349 --- deferred but now obsolete?

The following deferred PEP seems to have become obsolete due to time/Python marching on: PEP 349 - Allow str() to return unicode strings https://www.python.org/dev/peps/pep-0349/ As there is now not non-unicode strings anymore (unless I am misunderstanding the PEP). What should the state of

  1   2   3   4   5   6   7   8   9   10   >