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
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 reported. For
example:
if 0:
return
if 1:
ACTIVITY SUMMARY (2019-06-28 - 2019-07-05)
Python tracker at https://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open7068 (+14)
closed 42192 (+53)
total 49260 (+67)
Open issues
16 matches
Mail list logo
