[Python-Dev] Re: Optimizing literal comparisons and contains

I guess that you're talking about https://github.com/python/cpython/pull/29810/files To be honest, I never looked into Python/ast_opt.c. I expected a shorter implementation, a copy/paste or a few lines additions of "x == y" optimization. But it seems like "1 == 1" is not optimized neither. Oh. I

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Mon, Nov 29, 2021 at 1:21 AM Steve Holden wrote: > It's interesting that the egalitarian wish to allow use of native > "alphabetics" has turned out to be such a viper's nest. > Indeed. However, is there no way to restrict identifiers at least to the alphabets of natural languages? Maybe it

[Python-Dev] Re: Optimizing literal comparisons and contains

I also agree with this analysis. I’ll just add that any discussion about optimization needs to also show some data, for let’s say both contrived examples (like this one IMHO) and as real-world examples as possible. Sometimes “obvious” optimizations fool you and things actually get slower. Or

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Mon, Nov 15, 2021 at 8:42 AM Kyle Stanley wrote: > On Sat, Nov 13, 2021 at 5:04 PM wrote: > >> >> >> def 횑퓮햑풍표(): >> > [... Python code it's easy to believe isn't grammatical ...] > return ₛ >> > > 0_o color me impressed, I did not think that would be legal syntax. Would > be

[Python-Dev] Re: Optimizing literal comparisons and contains

Hi, I am surprised by the insistence on this thread for excluding comparisons from constant folding. Why should we special case comparisons? Am I missing something here? We already constant fold a variety of expressions 0 * 7 '' * 7 True - True True * False (All the above are falsey)

[Python-Dev] Re: Optimizing literal comparisons and contains

On Mon, 29 Nov 2021 12:32:19 + Mark Shannon wrote: > Hi, > > I am surprised by the insistence on this thread for excluding comparisons > from constant folding. > Why should we special case comparisons? Am I missing something here? Is it actually special-cased or is it just not implemented?

[Python-Dev] Re: Optimizing literal comparisons and contains

On Mon, Nov 29, 2021 at 12:32:19PM +, Mark Shannon wrote: > Hi, > > I am surprised by the insistence on this thread for excluding comparisons > from constant folding. > Why should we special case comparisons? Am I missing something here? We[1] are worried that the benefit gained will not be

[Python-Dev] Re: Optimizing literal comparisons and contains

29.11.21 14:32, Mark Shannon пише: > Excluding  1 < 2 seems inconsistent. It is not excluded, it is just not included. There should be reasons for adding any feature, and the benefit should exceed the cost. ___ Python-Dev mailing list --

[Python-Dev] Re: The current state of typing PEPs

On 11/29/21 2:56 PM, Barry Warsaw wrote: PEP 563 and 649 have visible effects that even within that domain can have important side effects. For example, PEP 563’s loss of local scope, which even “de-stringify-ing” can’t recover. This is what we need help with. Well, sure.  If PEP 563 and

[Python-Dev] Re: The current state of typing PEPs

Here's a use case for runtime type annotations: dataclasses use annotations to define fields. With the exception of ClassVar, the actual type is ignored. There's code in dataclasses.py to deal with stringized annotations, specifically just looking for ClassVar. I'd like to see this special

[Python-Dev] Re: The current state of typing PEPs

On Mon, Nov 29, 2021 at 07:56:16PM -0500, Terry Reedy wrote: > Maybe it should be reiterated with whatever decision comes forth that > > >>> def muladd(x, y, z): > ... return x * (y+z) > ... [...] > and other duck-typed code will always be legal, idiomatic, and even > expected as good

[Python-Dev] Re: The current state of typing PEPs

On 11/29/2021 5:56 PM, Barry Warsaw wrote: On Nov 25, 2021, at 13:41, Christopher Barker wrote: What is their role? Up to today, I have treated them as an advanced feature, useful for "complex codebases". But there are any number of examples springing up on the internet, to the point where

[Python-Dev] Re: The current state of typing PEPs

On Nov 29, 2021, at 15:57, Larry Hastings wrote: > > On 11/29/21 2:56 PM, Barry Warsaw wrote: >> PEP 563 and 649 have visible effects that even within that domain can have >> important side effects. For example, PEP 563’s loss of local scope, which >> even “de-stringify-ing” can’t recover.

[Python-Dev] Re: The current state of typing PEPs

On Mon, Nov 29, 2021 at 8:17 PM Guido van Rossum wrote: > Why would it need to be reiterated? Are there really people who believe > that such code would become invalid? AFAIK *everybody* here agrees that > this should stay valid. So who would we be reiterating it for? > I'm certainly not alone,

[Python-Dev] Re: The current state of typing PEPs

On 11/29/21 7:10 PM, Inada Naoki wrote: Anyone against making a statement that "PEP 563 will never be the default behavior"? I think only the SC is empowered to make such a statement. Then, we do not need to decide "PEP 563 or 649". We can focus on whether we can replace "stock semantics +

[Python-Dev] Re: The current state of typing PEPs

On Mon, Nov 29, 2021 at 5:01 PM Terry Reedy wrote: > On 11/29/2021 5:56 PM, Barry Warsaw wrote: > > > On Nov 25, 2021, at 13:41, Christopher Barker > wrote: > >> What is their role? Up to today, I have treated them as an advanced > feature, useful for "complex codebases". But there are any

[Python-Dev] Re: The current state of typing PEPs

On Nov 26, 2021, at 01:13, Paul Moore wrote: > I'd therefore interpret Barry's plea as being for *anyone* with a use > for annotations to provide their feedback (at least, anyone who > accepts that annotations are types), with particular emphasis on > people who want to use the types declared in

[Python-Dev] Re: The current state of typing PEPs

On 11/30/2021 1:16 AM, Guido van Rossum wrote: Why would it need to be reiterated? Are there really people who believe that such code would become invalid? AFAIK *everybody* here agrees that this should stay valid. So who would we be reiterating it for? (Yes, several static type checkers have

[Python-Dev] Re: The current state of typing PEPs

I hope my understanding of where the SC’s debate about this currently sits isn’t a misrepresentation, but since I sent the email on behalf of the SC, let me try to clarify what I was trying to say. Aside: A little insight into how the SC works. For communications like this, after whatever

[Python-Dev] Re: The current state of typing PEPs

On 11/29/2021 8:16 PM, Guido van Rossum wrote: On Mon, Nov 29, 2021 at 5:01 PM Terry Reedy > wrote: On 11/29/2021 5:56 PM, Barry Warsaw wrote: > On Nov 25, 2021, at 13:41, Christopher Barker mailto:python...@gmail.com>> wrote: >> What is their role?

[Python-Dev] Re: The current state of typing PEPs

I don't think the issue of how typing is making its way intot he community is particular relevant to this thread, but I was directly asked a question, so I'll answer it: I don't know exactly where the impression is coming from that typing is a best practice, but it's certainly creeping into

[Python-Dev] Re: The current state of typing PEPs

On Thu, Nov 18, 2021 at 8:00 AM Barry Warsaw wrote: > > Does PEP 563 or 649 satisfy static and dynamic typing needs? > > In the interest of full transparency, we want to let the Python community > know that the Steering Council continues to discuss PEP 563 (Postponed > Evaluation of

[Python-Dev] Re: Optimizing literal comparisons and contains

You should consider "no longer have to justify why it's not optimized" as a clear benefit of making this change :-) This optimization is proposed once a year for many years... For me, any possible compilation-ahead optimization (which doesn't break the Python semantics) is worth it ;-) It's done

[Python-Dev] Re: Optimizing literal comparisons and contains

29.11.21 18:36, Victor Stinner пише: > You should consider "no longer have to justify why it's not optimized" > as a clear benefit of making this change :-) This optimization is > proposed once a year for many years... > > For me, any possible compilation-ahead optimization (which doesn't > break

[Python-Dev] Re: Optimizing literal comparisons and contains

I agree with Serhiy's analysis. On Mon, 29 Nov 2021 at 17:10, Serhiy Storchaka wrote: > 29.11.21 18:36, Victor Stinner пише: > > You should consider "no longer have to justify why it's not optimized" > > as a clear benefit of making this change :-) This optimization is > > proposed once a year