Hi Fabio Does the actual function object get re-created as well during the recompilation process that you have described? Perhaps it might help to note that the __code__ attribute of a function object f can be mutated and that f is hashable?
Cheers, Gabriele On Thu, 17 Feb 2022 at 19:33, Fabio Zadrozny <fabi...@gmail.com> wrote: > > > Em qui., 17 de fev. de 2022 às 16:05, Mark Shannon <m...@hotpy.org> escreveu: >> >> Hi Fabio, >> >> This happened as part of implementing PEP 626. >> The previous behavior isn't very robust w.r.t doc strings and >> compiler optimizations. >> >> OOI, why would you want to revert to the old behavior? >> > > Hi Mark, > > The issue I'm facing is that ipython uses an approach of obtaining the ast > for a function to be executed and then it goes on node by node executing it. > > When running in the debugger, the debugger caches some information based on > (co_firstlineno, co_name, co_filename) to have information saved across > multiple calls to the same function, which works in general because each > function in a given python file would have its own co_firstlineno, but in > this specific case here it gets a single function and then recompiles it > expression by expression -- so, it'll have the same co_filename (<cell>) and > the same co_name (<module>), but then the co_firstlineno would be different > (because the statement resides in a different line), but with Python 3.10 > this assumption fails as even the co_firstlineno will be the same... > > You can see the actual issues at: > https://github.com/microsoft/vscode-jupyter/issues/8803 / > https://github.com/ipython/ipykernel/issues/841/ > https://github.com/microsoft/debugpy/issues/844 > > After thinkering a bit it seems it's possible to create a new code object > based on an existing code object with `code.replace` (re-assembling the > co_lnotab/co_firstlineno), so, I'm going to propose that as a fix to ipython, > but I found it really strange that this did change in Python 3.10 in the > first place as the old behavior seemed reasonable for me (i.e.: with the new > behavior it's a bit strange that the user is compiling something with a > single statement on line 99 and yet the resulting code object will have the > co_firstlineno == 1). > > -- note: I also couldn't find any mention of this in the changelog, so, I > thought this could've happened by mistake. > > Best regards, > > Fabio > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/DVP4VK3BY4XDC6B6HSVPLJTPCQKISAPC/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- "Egli è scritto in lingua matematica, e i caratteri son triangoli, cerchi, ed altre figure geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola; senza questi è un aggirarsi vanamente per un oscuro laberinto." -- G. Galilei, Il saggiatore. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/O5EEGEHE7G6UFTYO4UX7Y7QHZXA4ACYG/ Code of Conduct: http://python.org/psf/codeofconduct/
