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.
Related
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?
so I recently started looking into GUIs and I'm looking at a source code for the game wormy which can be found: here. I just have a few questions regarding this source code.
What does the sys module do in this code? I know that the sys module provides information about constants, functions and methods of the Python interpreter (taken from a website), but in this source code the only thing that the sys module is actually doing is being imported and then terminated when the game is closed? So I'm a bit confused about that.
In addition, I am wondering on how I can change the squares to look like circles instead? I tried changing the module functions (Rect and draw.rect) to draw.circle but an error keeps popping up. Any suggestions? Thanks!
When using pygame.draw.circle(), it will take different arguments than rect(). Look at the documentation here. Post your code and your error message for better help.
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 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.
I am trying to learn how Python reloads modules, but have hit a roadblock.
Let's say I have:
dir1\file1.py:
from dir2.file2 import ClassOne
myObject = ClassOne()
dir1\dir2\file2.py:
class ClassOne():
def reload_module():
reload(file2)
The reload call fails to find module "file2".
My question is, how do I do this properly, without having to keep everything in one file?
A related question: When the reload does work, will myObject use the new code?
thank you
def reload_module():
import file2
reload(file2)
However, this will not per se change the type of objects you've instantiated from classes held in the previous version of file2. The Python Cookbook 2nd edition has a recipe on how to accomplish such feats, and it's far too long and complex in both code and discussion to reproduce here (I believe you can read it on google book search, or failing that the original "raw" version [before all the enhancements we did to it], at least, should still be on the activestate cookbook online site).