[issue34880] About the "assert" bytecode

Serhiy Storchaka added the comment: Thank you Zackery for your contribution. > where ".AssertionError" is a name-mangled free variable and is assigned once > the module is executed. But this still allows to overriding builtin AssertionError before importing a module. And this solution

[issue34880] About the "assert" bytecode

Serhiy Storchaka added the comment: New changeset ce6a070414ed1e1374d1e6212bfbff61b6d5d755 by Serhiy Storchaka (Zackery Spytz) in branch 'master': bpo-34880: Add the LOAD_ASSERTION_ERROR opcode. (GH-15073) https://github.com/python/cpython/commit/ce6a070414ed1e1374d1e6212bfbff61b6d5d755

[issue34880] About the "assert" bytecode

Change by Armin Rigo : -- nosy: -arigo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34880] About the "assert" bytecode

Change by Zackery Spytz : -- components: +Interpreter Core nosy: +ZackerySpytz versions: +Python 3.9 -Python 3.8 ___ Python tracker ___

[issue34880] About the "assert" bytecode

Change by Zackery Spytz : -- keywords: +patch pull_requests: +14820 stage: -> patch review pull_request: https://github.com/python/cpython/pull/15073 ___ Python tracker ___

[issue34880] About the "assert" bytecode

thautwarm added the comment: Hi, Serhiy, there could be an another way to fix all this sort of problems IMO. We can figure out all the cases that implicitly require shadow builtins, and then change symtable visitor to add corresponding free variables with name mangling, for instance: 1.

[issue34880] About the "assert" bytecode

Serhiy Storchaka added the comment: This can't be changed in 3.6. There are two ways of changing it: 1. Make the marshal module supporting AssertionError as it supports booleans, None, Ellipsis and StopIteration. This will require adding the new marshal format version. 2. Add a new opcode

[issue34880] About the "assert" bytecode

Armin Rigo added the comment: A middle ground might be to copy the behavior of ``__import__``: it is loaded from the builtins module where specific hacks can change its definition, but it is not loaded from the globals. -- nosy: +arigo ___ Python

[issue34880] About the "assert" bytecode

Neil Schemenauer added the comment: Assuming it is not crazy complicated to fix, I would like to to be changed. It should work like the TypeError example. That fact that it has worked the current way since Python 1.5 isn't a strong argument. I think no one should be surprised if it

[issue34880] About the "assert" bytecode

Steven D'Aprano added the comment: > And, I think a broader discussion on python-dev might be useful, too, in > order to get more opinions. Done: https://mail.python.org/pipermail/python-dev/2018-October/155410.html Changing the status to Pending until we have more clarity on whether this

[issue34880] About the "assert" bytecode

Steven D'Aprano added the comment: On Wed, Oct 03, 2018 at 01:56:00PM +, Eric V. Smith wrote: > I think this is a bug that should be fixed. Supporting this position, shadowing other exceptions doesn't change the exception generated by the interpreter: py> TypeError = None py> 1 + "a"

[issue34880] About the "assert" bytecode

Eric V. Smith added the comment: I think this is a bug that should be fixed. This is similar to how f-strings used to work: the generated byte code would call format(something-or-other), and if you'd defined a name "format" in your code it would fail. Now admittedly "format" is more common

[issue34880] About the "assert" bytecode

thautwarm added the comment: Reply to this: > How is that different from every other case of shadowing a builtin? > > len = 45 > print(len("hello world")) ``` AssertionError = 42 assert 1 != 2 ``` `assert` implicitly invokes `AssertionError`, while `len` does that explicitly. That is to

[issue34880] About the "assert" bytecode

Steven D'Aprano added the comment: On Wed, Oct 03, 2018 at 09:49:06AM +, thautwarm wrote: > Steven, this problem is quite interesting because it just allows users > to cause fatal errors without any invalid operations. How is that different from every other case of shadowing a builtin?

[issue34880] About the "assert" bytecode

thautwarm added the comment: If we could generate `LOAD_CONST` instructions for `assert` statements, any prospective dangers could be avoided. ``` from dis import dis @dis def f(): assert x 3 0 LOAD_GLOBAL 0 (x) 2 POP_JUMP_IF_TRUE 8

[issue34880] About the "assert" bytecode

thautwarm added the comment: Steven, this problem is quite interesting because it just allows users to cause fatal errors without any invalid operations. ``` AssertionError = 1 assert 1 == 2, 2 --- TypeError: 'int'

[issue34880] About the "assert" bytecode

Steven D'Aprano added the comment: If I have understood you correctly, you are asking whether it is expected behaviour for assert to use the global AssertionError instead of the built-in AssertionError. I don't see why it shouldn't. In any case, that behaviour goes back to Python 1.5 and

[issue34880] About the "assert" bytecode

New submission from vtheno athena : When I was involved in the YaPyPy project, I found a problem, An source "assert 0" will compile to an bytecode, On that bytecode sequence, it always raise a "AssertionError" from global, when we rewrite global "AssertionError" like here: ``` class