pre-edit stuff persists in a reloaded a module
Hi all, Python 2.7. I habitually work interactively in an Idle window. Occasionally I correct code, reload and find that edits fail to load. I understand that reloading is not guaranteed to reload everything, but I don't understand the exact mechanism and would appreciate some illumination. Right now I am totally bewildered, having deleted and garbage collected a module and an object, reloaded the module and remade the object and when I inspect the corrected source (inspect.getsource (Object.run)) I see the uncorrected source, which isn't even on the disk anymore. The command 'reload' correctly displays the name of the source, ending '.py', indicating that it recognizes the source being newer than the compile ending '.pyc'. After the reload, the pyc-file is newer, indicating that it has been recompiled. But the runtime error persist. So the recompile must have used the uncorrected old code. I could kill python with signal 15, but would prefer a targeted purge that doesn't wipe clean my Idle workbench. (I know I should upgrade to version 3. I will as soon as I get around to it. Hopefully that will fix the problem.) Thanks for comments Frederic -- https://mail.python.org/mailman/listinfo/python-list
Re: pre-edit stuff persists in a reloaded a module
Friedrich Rentsch wrote: > Hi all, > > Python 2.7. I habitually work interactively in an Idle window. > Occasionally I correct code, reload and find that edits fail to load. I > understand that reloading is not guaranteed to reload everything, but I > don't understand the exact mechanism and would appreciate some > illumination. Right now I am totally bewildered, having deleted and > garbage collected a module and an object, reloaded the module and remade > the object and when I inspect the corrected source (inspect.getsource > (Object.run)) I see the uncorrected source, which isn't even on the disk > anymore. The command 'reload' correctly displays the name of the source, > ending '.py', indicating that it recognizes the source being newer than > the compile ending '.pyc'. After the reload, the pyc-file is newer, > indicating that it has been recompiled. But the runtime error persist. > So the recompile must have used the uncorrected old code. I could kill > python with signal 15, but would prefer a targeted purge that doesn't > wipe clean my Idle workbench. (I know I should upgrade to version 3. I > will as soon as I get around to it. Hopefully that will fix the problem.) > > Thanks for comments (1) stay away from reload() (2) inspect.getsource() uses a cache that you should be able to clear with linecache.clear(): $ echo 'def f(): return "old"' > tmp.py $ python [...] >>> import inspect, tmp >>> inspect.getsource(tmp.f) 'def f(): return "old"\n' >>> [1]+ Angehalten python $ echo 'def f(): return "new"' > tmp.py $ fg python reload(tmp) reload(tmp) >>> inspect.getsource(tmp.f) 'def f(): return "old"\n' >>> import linecache; linecache.clearcache() >>> inspect.getsource(tmp.f) 'def f(): return "new"\n' (3) see 1 ;) -- https://mail.python.org/mailman/listinfo/python-list
Re: pre-edit stuff persists in a reloaded a module
On 10/5/19 2:48 PM, Peter Otten wrote: Friedrich Rentsch wrote: Hi all, Python 2.7. I habitually work interactively in an Idle window. Occasionally I correct code, reload and find that edits fail to load. I understand that reloading is not guaranteed to reload everything, but I don't understand the exact mechanism and would appreciate some illumination. Right now I am totally bewildered, having deleted and garbage collected a module and an object, reloaded the module and remade the object and when I inspect the corrected source (inspect.getsource (Object.run)) I see the uncorrected source, which isn't even on the disk anymore. The command 'reload' correctly displays the name of the source, ending '.py', indicating that it recognizes the source being newer than the compile ending '.pyc'. After the reload, the pyc-file is newer, indicating that it has been recompiled. But the runtime error persist. So the recompile must have used the uncorrected old code. I could kill python with signal 15, but would prefer a targeted purge that doesn't wipe clean my Idle workbench. (I know I should upgrade to version 3. I will as soon as I get around to it. Hopefully that will fix the problem.) Thanks for comments (1) stay away from reload() (2) inspect.getsource() uses a cache that you should be able to clear with linecache.clear(): $ echo 'def f(): return "old"' > tmp.py $ python [...] import inspect, tmp inspect.getsource(tmp.f) 'def f(): return "old"\n' [1]+ Angehalten python $ echo 'def f(): return "new"' > tmp.py $ fg python reload(tmp) reload(tmp) inspect.getsource(tmp.f) 'def f(): return "old"\n' import linecache; linecache.clearcache() inspect.getsource(tmp.f) 'def f(): return "new"\n' (3) see 1 ;) Thank you, Peter. I guess, then, that not only 'inspect', but the compiler as well reads source off the line cache and clearing the latter would make 'reload' work as expected. Are there other snags lurking, that you advise against using 'reload'? What are the alternatives for developing iteratively, alternating between running and editing? Frederic -- https://mail.python.org/mailman/listinfo/python-list
Re: pre-edit stuff persists in a reloaded a module
On 10/5/2019 10:24 AM, Friedrich Rentsch wrote: Thank you, Peter. I guess, then, that not only 'inspect', but the compiler as well reads source off the line cache and clearing the latter would make 'reload' work as expected. Are there other snags lurking, that you advise against using 'reload'? Existing references to objects may continue to refer to old versions after loading new definitions. I never use reload. What are the alternatives for developing iteratively, alternating between running and editing? IDLE used properly is great for this. Edit and hit F5 to save and run. I personally recommend changing the Option Settings General tab 'At Start of Run (F5)' to (*) No Prompt. Note that if you get an exception (in the Shell), right click on appropriate line of the traceback and click 'Goto File/line' to go to the line in the editor. And IDLE (and Python) for 3.7+ has multiple improvements over IDLE for 2.7, so unless you need to specifically edit 2.7 code, do upgrade. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: pre-edit stuff persists in a reloaded a module
Friedrich Rentsch wrote: > > > On 10/5/19 2:48 PM, Peter Otten wrote: >> Friedrich Rentsch wrote: >> >>> Hi all, >>> >>> Python 2.7. I habitually work interactively in an Idle window. >>> Occasionally I correct code, reload and find that edits fail to load. I >>> understand that reloading is not guaranteed to reload everything, but I >>> don't understand the exact mechanism and would appreciate some >>> illumination. Right now I am totally bewildered, having deleted and >>> garbage collected a module and an object, reloaded the module and remade >>> the object and when I inspect the corrected source (inspect.getsource >>> (Object.run)) I see the uncorrected source, which isn't even on the disk >>> anymore. The command 'reload' correctly displays the name of the source, >>> ending '.py', indicating that it recognizes the source being newer than >>> the compile ending '.pyc'. After the reload, the pyc-file is newer, >>> indicating that it has been recompiled. But the runtime error persist. >>> So the recompile must have used the uncorrected old code. I could kill >>> python with signal 15, but would prefer a targeted purge that doesn't >>> wipe clean my Idle workbench. (I know I should upgrade to version 3. I >>> will as soon as I get around to it. Hopefully that will fix the >>> problem.) >>> >>> Thanks for comments >> (1) stay away from reload() >> (2) inspect.getsource() uses a cache that you should be able to clear >> with linecache.clear(): >> >> $ echo 'def f(): return "old"' > tmp.py >> $ python >> [...] > import inspect, tmp > inspect.getsource(tmp.f) >> 'def f(): return "old"\n' >> [1]+ Angehalten python >> $ echo 'def f(): return "new"' > tmp.py >> $ fg >> python >> reload(tmp) >> reload(tmp) >> > inspect.getsource(tmp.f) >> 'def f(): return "old"\n' > import linecache; linecache.clearcache() > inspect.getsource(tmp.f) >> 'def f(): return "new"\n' >> >> (3) see 1 ;) >> > Thank you, Peter. I guess, then, that not only 'inspect', but the > compiler as well reads source off the line cache and clearing the latter > would make 'reload' work as expected. I don't think so. My understanding may be incomplete, but my working assumption is that the module is reloaded from file, compiled, and new bindings overwrite old ones. However, every name bound to something from the old version will not be updated, i. e. import module obj = module.obj reload(module) assert obj is not module.obj > Are there other snags lurking, > that you advise against using 'reload'? The above scenario is enough for me to forego reload(). You are actually lucky when something fails as an apparently successful change may fail in a fresh interpreter. > What are the alternatives for > developing iteratively, alternating between running and editing? Keep the part under development small so that is doesn't hurt to rerun. -- https://mail.python.org/mailman/listinfo/python-list
Re: pre-edit stuff persists in a reloaded a module
On 10/5/2019 10:49 AM, Dennis Lee Bieber wrote: On Sat, 5 Oct 2019 16:24:14 +0200, Friedrich Rentsch declaimed the following: Thank you, Peter. I guess, then, that not only 'inspect', but the compiler as well reads source off the line cache and clearing the latter would make 'reload' work as expected. Are there other snags lurking, that you advise against using 'reload'? What are the alternatives for developing iteratively, alternating between running and editing? The simplest is to open a separate shell/console for running, and save from the editor before doing each run. Or try something other than IDLE, though pretty much any IDE that provides interactive access could fall a foul of this problem (the execute-in-separate console means a clean interpreter for each run; Actually running from the IDLE editor, as opposed to reloading in the shell, gives a clean interpreter, in a new subprocess, for each run. Plus it has some advantages over separated editor and console REPL. The first is that it compile()s the code to check syntax before starting the subprocess. If there is an error, IDLE highlights the error location and puts the cursor there so one can correct it. The last, which I mentioned in response to Friedrich, is the ability to jump back to the location of runtime exceptions. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Get __name__ in C extension module
On 10/4/19 4:30 PM, Ian Pilcher wrote: Ideally, I would pass my existing Logging.logger object into my C function and use PyObject_CallMethod to call the appropriate method on it (info, debug, etc.). As I've researched this further, I've realized that this isn't the correct approach. My extension should be doing the C equivalent of: logger = logging.getLogger(__name__) This is straightforward, except that I cannot figure out how to retrieve the __name__. I can get it from the module object with PyModule_GetName, but that requires that I have a reference to the module object in order to do so. I would have thought that this would be easy for a module function to access, but I haven't been able to find any API which does this. (Module functions get NULL as their 'self' argument.) Any pointers appreciated. Thanks! -- Ian Pilcher [email protected] "I grew up before Mark Zuckerberg invented friendship" -- https://mail.python.org/mailman/listinfo/python-list
Re: ipython in different loctions.
On 03Oct2019 00:45, Hongyi Zhao wrote:
On Thu, 03 Oct 2019 10:19:23 +1000, Cameron Simpson wrote:
bash -x ~/.pyenv/shims/ipython3
and see what its final command does.
Tried as follows:
-
werner@localhost:~$ bash -x ~/.pyenv/shims/ipython3
[...]
+ exec /home/werner/.pyenv/libexec/pyenv exec ipython3
Python 3.7.4 (default, Aug 29 2019, 06:59:32)
[...]
In [1]:
-
Also tried the follows:
werner@localhost:~$ bash -x ~/.local/bin/ipython3
+ import re
+ import sys
+ from IPython import start_ipython
from: can't read /var/mail/IPython
/home/werner/.local/bin/ipython3: line 10: syntax error near unexpected
token `('
/home/werner/.local/bin/ipython3: line 10: `sys.argv[0] = re.sub(r'(-
script\.pyw?|\.exe)?$', '', sys.argv[0])'
werner@localhost:~$
The former can start the ipython, while the latter will fail.
That is because ~/.local/bin/ipython3 is not a shell script (thus syntax
errors). It is directly a python script.
Cheers,
Cameron Simpson
--
https://mail.python.org/mailman/listinfo/python-list
