The code in the pull request is not updated and cannot be updated (though I
seem to have fixed the bugs in the test in my modified CPython build). It won't
merge, and I definitely believe it won't pass.
___
Python-Dev mailing list --
If someone wants to experiment such optimization, there is no need to
modify the Python internal optimizer, it can be done externally:
https://faster-cpython.readthedocs.io/ast_optimizer.html
For example, I implemented many optimizations like constant
propagation and loop unrolling in my old AST
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
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
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
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
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
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 --
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
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?
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)
On 2021-11-29 00:52, Christopher Barker wrote:
I will frequently do simple computation with literals to make my code
more clear:
t = 2 * 3600 # 2 hours in seconds
But I see no need to optimize this kind of thing -- it would never be in
a tight loop.
The suggestion was specifically about
On Mon, Nov 29, 2021 at 10:11 AM Rob Cliffe via Python-Dev
wrote:
>
> I am slightly surprised that it seems to be *easier* to fold selected
> constant expressions than to have more generic code to fold them all.
> Or at least, all those that don't contain containers, such as
> 1 in [0,1,2]
On 11/28/2021 7:52 PM, Christopher Barker wrote:
I will frequently do simple computation with literals to make my code
more clear:
t = 2 * 3600 # 2 hours in seconds
That is optimized as you'd hope. Tested in 3.8:
>>> dis.dis("t = 2 * 3600")
1 0 LOAD_CONST 0 (7200)
I will frequently do simple computation with literals to make my code more
clear:
t = 2 * 3600 # 2 hours in seconds
But I see no need to optimize this kind of thing -- it would never be in a
tight loop.
-CHB
On Sun, Nov 28, 2021 at 3:06 PM Rob Cliffe via Python-Dev <
python-dev@python.org>
I am slightly surprised that it seems to be *easier* to fold selected
constant expressions than to have more generic code to fold them all.
Or at least, all those that don't contain containers, such as
1 in [0,1,2]
Rob Cliffe
On 28/11/2021 21:10, Eric V. Smith wrote:
On Nov 28, 2021, at
> On Nov 28, 2021, at 3:03 PM, Serhiy Storchaka wrote:
>
> 28.11.21 17:13, Skip Montanaro пише:
>>> That is not entirely true:
>>> https://github.com/python/cpython/pull/29639#issuecomment-974146979
>>
>> The only places I've seen "if 0:" or "if False:" in live code was for
>> debugging.
27.11.21 15:47, Jeremiah Vivian пише:
> Many operations involving two literals are optimized (to a certain level). So
> it sort of surprises me that literal comparisons are not optimized and
> literal contains only convert the right operand to a constant if possible.
> I'd like to implement
28.11.21 17:13, Skip Montanaro пише:
>> That is not entirely true:
>> https://github.com/python/cpython/pull/29639#issuecomment-974146979
>
> The only places I've seen "if 0:" or "if False:" in live code was for
> debugging. Optimizing that hardly seems necessary. In any case, the
> original
> That is not entirely true:
> https://github.com/python/cpython/pull/29639#issuecomment-974146979
The only places I've seen "if 0:" or "if False:" in live code was for
debugging. Optimizing that hardly seems necessary. In any case, the
original comment was about comparisons of two constants. I
On 28/11/2021 6:28 am, raymond.hettin...@gmail.com wrote:
For the benefit of the audience on python-dev, you should also mention that
this proposal and associated PR has been twice discussed and rejected on the
tracker:
https://bugs.python.org/issue45907
For the benefit of the audience on python-dev, you should also mention that
this proposal and associated PR has been twice discussed and rejected on the
tracker:
https://bugs.python.org/issue45907
https://bugs.python.org/issue45843
The response just given by Skip pretty much matches the
> Many operations involving two literals are optimized (to a certain level). So
> it sort of surprises me that literal comparisons are not optimized and
> literal contains only convert the right operand to a constant if possible.
> I'd like to implement optimizations for these especially for
23 matches
Mail list logo
