>. If it doesn't, could this one optimization
be left in the peephole optimizer at bytecode level?
Sadly no, because at that time there is not enough information left to do
things correctly. The problem manifest with constructs like
if something or __debug__:
...
You cannot just look at the
On Mon, Jul 8, 2019 at 1:51 PM Brett Cannon wrote:
> Hopefully Pablo's proposed solution works.
I'm sure it will.
> If it doesn't, could this one optimization be left in the peephole
> optimizer at bytecode level? Otherwise is another solution to follow
> through with
>
Hopefully Pablo's proposed solution works. If it doesn't, could this one
optimization be left in the peephole optimizer at bytecode level? Otherwise is
another solution to follow through with
https://discuss.python.org/t/switch-pythons-parsing-tech-to-something-more-powerful-than-ll-1/379
and
Thanks Terry for your comments!
> I presume that most of us agree that the last option, doing both, would be
> best, or at least agreeable.
I created a PR reverting the change but I (may) have found a way of doing both
things :)
___
Python-Dev
Ok, I think I found a way to make everyone happy. I have updated the issue
and the PR with the solution.
Basically the idea is to add an attribute to the compiler that is checked
when emitting the bytecode
and if is false, we stop don't emit anything but we do check for errors.
Unless I am
This thread is based on https://bugs.python.org/issue37500
to get the thoughts of a broader range of people.
On 7/5/2019 5:28 PM, Pablo Galindo Salgado wrote:
Recently, we moved the optimization for the removal of dead code of the form
if 0:
to the ast
My impression is that you
That's a bit of a fine line to walk. I noticed it when writing tests for
IPython, which is not a implementation of Python, but is dealing with the nitty
gritty details and manipulating the syntax tree it's true, but it's roughly the
same class of project as implementing coverage.py, so if we
I think this summarizes the situation very well :)
https://xkcd.com/1172/
On Fri, 5 Jul 2019 at 22:28, Pablo Galindo Salgado
wrote:
> Hi,
>
> Recently, we moved the optimization for the removal of dead code of the
> form
>
> if 0:
>
>
> to the ast so we use JUMP bytecodes instead (being
I can understand the desire for correctness. I do have to wonder
though: has anyone *other* than language implementors noticed this issue
with SyntaxErrors not being reported?
Perhaps we should remember "Practicality beats purity"?
--Ned.
On 7/5/19 6:14 PM, Pablo Galindo Salgado wrote:
>
On 2019-07-06, Victor Stinner wrote:
> More people seems to expect "if 0: ..." to be removed, than people who
> care of syntax errors on "if 0".
One small data point: I have shipped code that depended on 'if 0'
removing code from the .pyc file. The code inside was not meant to
be released
> You started your msg by saying "we moved the optimization", but that's
not so: the optimization was eliminated. So just finish "moving" it
;-)
PR14116 was "finishing" the moving by adding JUMPS (a weaker optimization
but still an optimization).
> We should revert the change until someone
[Pablo Galindo Salgado ]
> Recently, we moved the optimization for the removal of dead code of the form
>
> if 0:
>
>
> to the ast so we use JUMP bytecodes instead (being completed in PR14116). The
> reason is that currently, any syntax error in the block will never be
> reported.
> For
> Until a solution which makes everyone happy can be found, I suggest to
move back to the status quo: revert the change.
>More people seems to expect "if 0: ..." to be removed, than people who
care of syntax errors on "if 0".
I don't think this is that clear. As Paul wrote on the issue this is
It seems that the issue that originally caused compatibility issues was
that `__debug__` statements were being optimized away, which was
apparently desirable from coverage's point of view. It's not clear to
me, but it seems that this may also impact what bytecode is generated
when Python is run in
Hi,
Until a solution which makes everyone happy can be found, I suggest to
move back to the status quo: revert the change.
More people seems to expect "if 0: ..." to be removed, than people who
care of syntax errors on "if 0".
--
Would it be possible to detect if the "if 0" block would raise a
On Jul 5, 2019, at 17:28, Pablo Galindo Salgado wrote:
> [...]
> I am writing this email to know what other people think. Should we revert the
> change and not report Syntax Errors on optimized blocks? Someone
> sees a viable way of reporting the errors and not emitting the bytecode for
> these
On 06.07.2019 0:28, Pablo Galindo Salgado wrote:
Hi,
Recently, we moved the optimization for the removal of dead code of the form
if 0:
to the ast so we use JUMP bytecodes instead (being completed in PR14116). The
reason is that
currently, any syntax error in the block will never be
17 matches
Mail list logo