[Python-Dev] Re: I plan to accept PEP 623 "Remove wstr from Unicode" next week

Thank you Victor for PEP-Delegating and accepting. Reducing 8bytes per str object (or 16bytes per non-ASCII str object) will be a significant win for all Python users. On Wed, Jul 15, 2020 at 8:20 AM Victor Stinner wrote: > > Hi, > > I have the pleasure of announcing that I accept the PEP 623

[Python-Dev] Re: I plan to accept PEP 623 "Remove wstr from Unicode" next week

Hi, I have the pleasure of announcing that I accept the PEP 623 "Remove wstr from Unicode", congratulations INADA-san! I see this PEP as a good way to better communicate on incoming backward incompatible C API changes. The PEP is a good document to explain the Motivation, the Rationale and also

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

On 07/14/2020 11:05 AM, Mark Shannon wrote: On 14/07/2020 5:25 pm, Tobias Kohn wrote: On 07/14/2020, Mark Shannon wrote: In future, could you avoid editing emails when replying to them? A lot of context can get lost. I appreciate posters who take the time to trim the parts of an email that

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

Hi Tobias, In future, could you avoid editing emails when replying to them? A lot of context can get lost. On 14/07/2020 5:25 pm, Tobias Kohn wrote: Hi Mark, Thank you for your message.  I might be able to answer some of the questions and also address some issues with the underlying

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

On 07/14/2020 09:22 AM, Jim J. Jewett wrote: Larry Hastings wrote: As for leveraging the convention of using '_' for values you don't care about in Python--that's actually why I /don't/ like it as the wildcard pattern.  To date, everyone who uses '_' understands it's just an identifier, no

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

Hi Mark, Thank you for your message.  I might be able to answer some of the questions and also address some issues with the underlying assumptions in your email---after all, we would most certainly want to avoid discussing and reasoning about straw men, as you yourself have repeatedly

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

Larry Hastings wrote: > As for leveraging the convention of using '_' for values you don't care > about in Python--that's actually why I /don't/ like it as the wildcard > pattern.  To date, everyone who uses '_' understands it's just an > identifier, no different from any other identifier.

[Python-Dev] BPO-41182 - Update

Hi Team, I am waiting for a review on https://github.com/python/cpython/pull/21257. It would be great if someone can take a look at it and move PR forward. Thanks in advance. -- Thanks, Abhijeet Kasurde ___ Python-Dev mailing list --

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

On 7/12/20 3:20 PM, Guido van Rossum wrote: On Sun, Jul 12, 2020 at 12:12 PM Larry Hastings > wrote: Having thought about it some, I propose it'd be acceptable to do dead store optimization if-and-only-if optimizations are explicitly enabled, e.g. with

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

Hi, As I wrote in an earlier email: For a PEP to succeed it needs to show two things. 1. Exactly what problem is being solved, or need is to be fulfilled, and that is a sufficiently large problem, or need, to merit the proposed change. 2. That the proposed change is the best known solution

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

On 13/07/2020 19:17, Guido van Rossum wrote: I find it debatable that we should have this at all, since there are other interpretations possible, and honestly I doubt that it’s a common use case. That’s why we’re holding off. Fair enough. All it would do would be save code in a guard