Fabio Zadrozny <fab...@users.sourceforge.net> added the comment:
@Mark @Brett Well, PEP 523 still works (it's just more inconvenient to use now). Still, if PEP 523 will still be supported I think that having the setter/getter makes sense. If it is to be deprecated as @Mark is suggesting it doesn't really make sense to add it (but then, it should really be deprecated and ideally there'd be some replacement for the current debugger use... not sure about other use cases such as a jit, which was the initial target of PEP 523 -- @Mark, do you want to go that route/create a PEP to deprecate it so that this discussion takes place in a proper place?). p.s.: as a note, bytecode modification on the actual object is not a usable approach for the debugger because users could break that in real-world use cases (i.e.: what happens if the user creates a **new** code and sets it to the code which had the breakpoint? What about breakpoint changes? Right now the debugger evaluates all assumptions just before the frame is executed, so, it's easier to get things right -- the case you posted currently does what's expected on pydevd). Still, a callback before the execution so that it could change the frame code before it's executed without the remainder of PEP 523 would be enough (and maybe it could be adopted in other Python implementations too) -- actually, for the debugger it'd be awesome if the frame code could be changed from inside a trace call and then that stack would restart execution (close to what happens with setting the frame line to be executed), but I guess this would be a completely different request ;) p.s.: please don't reply to my previous p.s. here (let's move the discussion to another place -- either by @Mark creating a PEP for discussion or acknowledging the issue is ok given the current status quo). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38500> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
