How to reload **builtin** module sys in python? - python

This is a theoretical or experimental question.
I am searching for generality here. "Does a method apply to every possible appliable object?"
I recently asked about how to reload builtin-modules.
Here is the result so far : link
As far as I know, we need to delete sys.modules['package_name'] and package_name.
Does this method apply to all the other built-in library?
Well maybe. But I tried to delete sys and reload it, I failed. It seems that for importing we need sys package because import searchs sys.modules.
So my question is how can i reload the built-in package sys? I wont accept any answer like "Don't do it". I know that I won't have a chance to use this or it's much faster just to restart python but I might understand more about python searching for this answer, so is there any chance to reloading sys?

Related

Not able to understand the implementation of the os module in cpython

So I wanted to check out some implementations of standard libraries. I started with the os library with the code being here on github.
I took one method for example os.listdir() and I have absolutely no idea how it is implemented even after looking at the code ( pardon this noob ). I have following questions:
os.__all__ do not list this method but I think it is definitely a method as print(type(os.listdir)) listed <class 'builtin_function_or_method'> and I searched on google to find all the builtin functions which I found on this doc page and this is not one of them.
There is not such exclusive function named listdir defined in the module. In the code, from my limited understanding, the function is taken from globals() and put into a support_fd set. How this method is being called I do not understand.
I think the main problem I have is how that module is designed and I was not able to find any resources online to explain in simpler terms hence I am asking here for pointers.
EDIT: For those who are asking, I tried the following code in onlinegdb
import os
if "listdir" in os.__all__:
print("Yes")
print(os.listdir())
The result is only main.py, it should also print Yes, maybe the platform onlinegdb is the problem but it clearly shows the output of listdir as main.py.
After having discussion in the comments I see now that this is more of a online python version problem and not an issue with python or the module itself.

Python: Calling a function from a file that has current file imported

I tried searching around but didn't seem to find an answer to my problem, so I'm sorry if I missed something and it actually has been answered before.
So basically I have main.py and another file called check.py (both in same directory)
In my main.py I have:
from check import checkfunction
I have a small function inside main.py that I MUST call inside check.py, but I can't seem to get this import working on my check.py:
from main import mainfunction
How can I get the mainfunction to work inside check.py?
Thanks!
You've got a design with a circular dependency which is usually a bad thing as your two python modules are tightly coupled.
Consider refactoring your code. But if you must stick with your design please see the following SO question for more info on how circular imports work in Python and the various gotchas to look out for.
Several options:
Move the common function to a module imported by both other modules.
Merge both modules into one.
Pass the function from main to the code that needs to call it.
Monkey patch the function into the check module after importing it.
Refactor the whole thing so that you don't have circular dependencies.
If you actually explained why you have this design, someone could possibly propose a better way.

how do you statically find dynamically loaded modules

How does one get (finds the location of) the dynamically imported modules from a python script ?
so, python from my understanding can dynamically (at run time) load modules.
Be it using _import_(module_name), or using the exec "from x import y", either using imp.find_module("module_name") and then imp.load_module(param1, param2, param3, param4) .
Knowing that I want to get all the dependencies for a python file. This would include getting (or at least I tried to) the dynamically loaded modules, those loaded either by using hard coded string objects or those returned by a function/method.
For normal import module_name and from x import y you can do either a manual scanning of the code or use module_finder.
So if I want to copy one python script and all its dependencies (including the custom dynamically loaded modules) how should I do that ?
You can't; the very nature of programming (in any language) means that you cannot predict what code will be executed without actually executing it. So you have no way of telling which modules could be included.
This is further confused by user-input, consider: __import__(sys.argv[1]).
There's a lot of theoretical information about the first problem, which is normally described as the Halting problem, the second just obviously can't be done.
From a theoretical perspective, you can never know exactly what/where modules are being imported. From a practical perspective, if you simply want to know where the modules are, check the module.__file__ attribute or run the script under python -v to find files when modules are loaded. This won't give you every module that could possibly be loaded, but will get most modules with mostly sane code.
See also: How do I find the location of Python module sources?
This is not possible to do 100% accurately. I answered a similar question here: Dependency Testing with Python
Just an idea and I'm not sure that it will work:
You could write a module that contains a wrapper for __builtin__.__import__. This wrapper would save a reference to the old __import__and then assign a function to __builtin__.__import__ that does the following:
whenever called, get the current stacktrace and work out the calling function. Maybe the information in the globals parameter to __import__ is enough.
get the module of that calling functions and store the name of this module and what will get imported
redirect the call the real __import__
After you have done this you can call your application with python -m magic_module yourapp.py. The magic module must store the information somewhere where you can retrieve it later.
That's quite of a question.
Static analysis is about predicting all possible run-time execution paths and making sure the program halts for specific input at all.
Which is equivalent to Halting Problem and unfortunately there is no generic solution.
The only way to resolve dynamic dependencies is to run the code.

Is there any possible point to reloading a Python module immediately?

Is there any conceivable point to reloading these modules immediately after importing them? This is the code that I was reviewing which made me wonder:
import time
import sys
import os
import string
import pp
import numpy
import nrrd
reload(nrrd)
import smooth as sm
reload(sm)
import TensorEval2C as tensPP
reload(tensPP)
import TrackFiber4C as trackPP
reload(trackPP)
import cmpV
reload(cmpV)
import vectors as vects
reload(vects)
Edit: I suggested that this might make the creation of .pyc files more likely, but several people pointed out that this happens this first time, every time.
I note that the standard modules are just imported: it's the other modules that are reloaded. I expect whoever wrote this code wanted to be able to easily reload the whole package (so as to get their latest edits). After putting in all these redundant reload calls, the programmer only had to write
>>> reload(package)
to bring things up to date in the interpreter, instead of having to type
>>> reload(package.nrrd)
>>> reload(package.sm)
>>> reload(package.tensPP)
etc. So please ignore the suggestion that you commit violence against the programmer who wrote this: they are far from the only programmer who's had trouble with reloading of dependencies. Just encourage them to move the reloads to a convenience function.
It is possible that this does cause something to happen; the obvious example is side-effects that happen on import. For instance, a module could log to a file the time and date of every time it is imported.
There is probably no good reason for this, however.
The .pyc files would be created on the first import, so even that's not a very good reason for this.
What's the execution environment for this code? There exists at least one Python web framework that makes different reload decisions than standard python does, which leads to frustration and confusion when you make a change that doesn't 'take'.

Python Auto Importing [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Perl's AUTOLOAD in Python (getattr on a module)
I'm coming from a PHP background and attempting to learn Python, and I want to be sure to do things the "Python way" instead of how i've developed before.
My question comes from the fact in PHP5 you can set up your code so if you attempt to call a class that doesn't exist in the namespace, a function will run first that will load the class in and allow you to continue on as if it were already loaded. the advantages to this is classes weren't loaded unless they were called, and you didn't have to worry about loading classes before using them.
In python, there's alot of emphasis on the import statement, is it bad practice to attempt an auto importing trick with python, to alleviate the need for an import statement? I've found this module that offers auto importing, however I dont know if that's the best way of doing it, or if auto importing of modules is something that is recommended, thoughts?
Imports serve at least two other important purposes besides making the modules or contents of the modules available:
They serve as a sort of declaration of intent -- "this module uses services from this other module" or "this module uses services belonging to a certain class" -- e.g. if you are doing a security review for socket-handling code, you can begin by only looking at modules that import socket (or other networking-related modules)
Imports serve as a proxy for the complexity of a module. If you find yourself with dozens of lines of imports, it may be time to reconsider your separation of concerns within the module, or within your application as a whole. This is also a good reason to avoid "from foo import *"-type imports.
In Python, people usually avoid auto imports, just because it is not worth the effort. You may slightly remove startup costs, but otherwise, there is no (or should be no) significant effect. If you have modules that are expensive to import and do a lot of stuff that doesn't need to be done, rather rewrite the module than delay importing it.
That said, there is nothing inherently wrong with auto imports. Because of the proxy nature, there may be some pitfalls (e.g. when looking at a thing that has not been imported yet). Several auto importing libraries are floating around.
If you are learning Python and want to do things the Python way, then just import the modules. It's very unusual to find autoimports in Python code.
You could auto-import the modules, but the most I have ever needed to import was about 10, and that is after I tacked features on top of the original program. You won't be importing a lot, and the names are very easy to remember.

Categories