> [Guido] > > Python should not include features (like writable code object > > attributes) that can cause crashes when used inexpertly. > > If I do implement this, I'll do it in such a way as to make crashes > impossible (my first suggestion said that crashes would be possible, > but I realise that was a mistake). It'll verify that the new value > of f_lasti is a valid bytecode position, and it'll either fix up the > stack/blockstack or refuse to move the position in ways that would > affect them. (Armin, I guess that won't restrict you because you're > doing this from C code?) Great. > [Armin] > > For safety I'd consider writing the > > frame-object-modifying code in a C extension module, carefully > > documented as "don't use this". > > [Guido] > > That's a reasonable solution: f_lasti should be read-only from > > Python code, but you can write an extension that can write it. > > I'd like to see pure Python debuggers (including pdb) have this > feature. If it's safe to use, might it still be considered for > inclusion? (I can't guarantee I'll have the time to do it, but I'll > try.) Sure, *if* it's safe. > I'm also coming to realise that it's not f_lasti I really want to > change, but f_lineno. The line number is the 'unit' that debuggers > use - a debugger would set f_lineno, and f_lasti would be calculated > and changed to the appropriate value. I don't think that changes > any of the arguments either way, except maybe to distance the idea a > little from what Armin is doing. Sure. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4