If you have a module like module, can you bypass it and use the functions available inside without using the module?
I imported the module, but the compiler still complains not having to find function. I still have to use module.function().
It has many more functions, so I don't want to redefine them one by one but just avoid typing module if possible.
Importing in Python just adds stuff to your namespace. How you qualify imported names is the difference between import foo and from foo import bar.
In the first case, you would only import the module name foo, and that's how you would reach anything in it, which is why you need to do foo.bar(). The second case, you explicitly import only bar, and now you can call it thus: bar().
from foo import * will import all importable names (those defined in a special variable __all__) into the current namespace. This, although works - is not recommend because you may end up accidentally overwriting an existing name.
foo = 42
from bar import * # bar contains a `foo`
print foo # whatever is from `bar`
The best practice is to import whatever you need:
from foo import a,b,c,d,e,f,g
Or you can alias the name
import foo as imported_foo
Bottom line - try to avoid from foo import *.
Related
I have a Python module with the following structure:
mymod/
__init__.py
tools.py
# __init__.py
from .tools import foo
# tools.py
def foo():
return 42
Now, when import mymod, I see that it has the following members:
mymod.foo()
mymod.tools.foo()
I don't want the latter though; it just pollutes the namespace.
Funnily enough, if tools.py is called foo.py you get what you want:
mymod.foo()
(Obviously, this only works if there is just one function per file.)
How do I avoid importing tools? Note that putting foo() into __init__.py is not an option. (In reality, there are many functions like foo which would absolutely clutter the file.)
The existence of the mymod.tools attribute is crucial to maintaining proper function of the import system. One of the normal invariants of Python imports is that if a module x.y is registered in sys.modules, then the x module has a y attribute referring to the x.y module. Otherwise, things like
import x.y
x.y.y_function()
break, and depending on the Python version, even
from x import y
can break. Even if you don't think you're doing any of the things that would break, other tools and modules rely on these invariants, and trying to remove the attribute causes a slew of compatibility problems that are nowhere near worth it.
Trying to make tools not show up in your mymod module's namespace is kind of like trying to not make "private" (leading-underscore) attributes show up in your objects' namespaces. It's not how Python is designed to work, and trying to force it to work that way causes more problems than it solves.
The leading-underscore convention isn't just for instance variables. You could mark your tools module with a leading underscore, renaming it to _tools. This would prevent it from getting picked up by from mymod import * imports (unless you explicitly put it in an __all__ list), and it'd change how IDEs and linters treat attempts to access it directly.
You are not importing the tools module, it's just available when you import the package like you're doing:
import mymod
You will have access to everything defined in the __init__ file and all the modules of this package:
import mymod
# Reference a module
mymod.tools
# Reference a member of a module
mymod.tools.foo
# And any other modules from this package
mymod.tools.subtools.func
When you import foo inside __init__ you are are just making foo available there just like if you have defined it there, but of course you defined it in tools which is a way to organize your package, so now since you imported it inside __init__ you can:
import mymod
mymod.foo()
Or you can import foo alone:
from mymod import foo
foo()
But you can import foo without making it available inside __init__, you can do the following which is exactly the same as the example above:
from mymod.tools import foo
foo()
You can use both approaches, they're both right, in all these example you are not "cluttering the file" as you can see accessing foo using mymod.tools.foo is namespaced so you can have multiple foos defined in other modules.
Try putting this in your __init__.py file:
from .tools import foo
del tools
I have a module foo.py, which I am importing in my file main.py, I have imports at the top of foo.py such as import numpy as np, etc.
Now, if I'm only calling a certain function fun(arg1, arg2, arg3), do the imports at the top of foo.py take place or do I have to add the imports inside the function definition of fun?
Also, does from foo import fun make a difference then import foo in this regard?
File foo.py (to be imported)
import numpy as np
def fun(arg1, arg2, arg3):
x = np.argsort(arg1)
return x
File main.py
import foo
call = fun([2, 34, 0, -1], 4, 5])
Or should I go with this in foo.py?
def fun(arg1, arg2, arg3):
import numpy as np
x = np.argsort(arg1)
return x
No you don't need to import it again inside fun. You can test this out, your code should work even if your import numpy only once at the top of foo.py.
The two ways don't make any difference except that if you import as import foo you have to refer to fun as foo.fun. If you do from foo import fun instead, you can just use fun.
When you import a module, python will execute all the statements in the module file. So, when you import foo, in either of the above two ways, it will run import numpy as np and update the private symbol table for foo. All statements, functions defined inside foo can use symbols in this table without any qualification. In your case, fun will have access to numpy as np.
What happens to numpy import itself is more interesting.
Case 1
from foo import fun
You are only importing fun nothing else. Whatever code in fun will run because of the above reasons, but np itself will be invisible to code in main.
Case 2
import foo
Here you will refer to fun as foo.fun like I said before, but np can also be used as foo.np but this is absolutely not recommended.
It's always best to import modules again if you are going to use them in the current file, don't rely on indirect imports from other files. Since, python caches imports you needn't worry about performance or circular imports.
Read about the import system to understand all this fully.
When the module is loaded for the first time, all the lines in it are run. imports, defs, regular assignments, etc. All these lines initialize a namespace that is the module object. The namespace of foo will have a variable np that points to the loaded numpy module, and a variable fun that points to your function object.
Functions are first class objects in python. In particular, they have a __globals__ (look under "Callable Types" in the linked docs) attribute, which points to the namespace of the module they were defined in. No matter what you do to the reference of foo.fun, the namenp will be available in the function until you delete it from foo itself.
It is not recommended that you import anything inside your function, unless you have good reason to do so, like avoiding a global name. When you import a module, the interpreter will first look into sys.modules. If it is found, the import will not take much longer than a lookup into the global dictionary. However, if the module hasn't been loaded yet, it will be right there and then. You may not want to incur that overhead at an arbitrary point in your program, especially one that may be time-sensitive.
As far as import form, the differences are mostly aesthetic, but they do have practical consequences as well. from foo import fun creates a name fun in your namespace, referring directly to the function object of interest. It contaminates your local namespace with an extra name, but saves you a lookup through foo's namespace dictionary every time you access the function. import foo, on the other hand, keeps everything bundled nicely since you have to call foo.fun, but that requires an extra lookup.
TL;DR
You should put all your imports at the top of your file. It doesn't really matter how you do it.
Don't need to import it again inside function fun().
For further, please check this
Which is a better practice - global import or local import
So i'm reading Alex Martelli's answer to other question...
"One example in which I may want initialization is when at package-load time I want to read in a bunch of data once and for all (from files, a DB, or the web, say) -- in which case it's much nicer to put that reading in a private function in the package's init.py rather than have a separate "initialization module" and redundantly import that module from every single real module in the package..."
Unfortunately, when i try this:
foo/__init__.py
import tables as tb
global foo
foo = tb.openFile('foo.h5', etc._)
import bar
foo/bar/__init__.py
import tables as tb
global bar
bar = foo.createGroup('/', bar)
import MyFunction`
foo/bar/MyFunction.py
def MyFunction(*of foo and bar*):
'...'
>>> import foo
>>> OUTPUT= foo.bar.MyFunction.MyFunction(INPUT)
>>> bar = foo.createGroup('/', bar)
NameError: name 'foo' is not defined
How does one define global variables without putting them in a function (as seen here)?
global variables are not global in the sense that every bit of python code sees the same set of globals. the global-ness is really just the 'module scope'; All of the variables and functions defined in a module are already global, and as global as they can possibly be.
If you want to see the variables defined in one module among the globals of another module, the only way to do it is to import the names of the first module into the second... IE:
# myModule.py
foo = "bar"
# yourModule.py
from myModule import foo
I am currently doing a python tutorial, but they use IDLE, and I opted to use the interpreter on terminal. So I had to find out how to import a module I created. At first I tried
import my_file
then I tried calling the function inside the module by itself, and it failed. I looked around and doing
my_file.function
works. I am very confused why this needs to be done if it was imported. Also, is there a way around it so that I can just call the function? Can anyone point me in the right direction. Thanks in advance.
If you wanted to use my_file.function by just calling function, try using the from keyword.
Instead of import my_file try from my_file import *.
You can also do this to only import parts of a module like so :
from my_file import function1, function2, class1
To avoid clashes in names, you can import things with a different name:
from my_file import function as awesomePythonFunction
EDIT:
Be careful with this, if you import two modules (myfile, myfile2) that both have the same function inside, function will will point to the function in whatever module you imported last. This could make interesting things happen if you are unaware of it.
This is a central concept to python. It uses namespaces (see the last line of import this). The idea is that with thousands of people writing many different modules, the likelihood of a name collision is reasonably high. For example, I write module foo which provides function baz and Joe Smith writes module bar which provides a function baz. My baz is not the same as Joe Smiths, so in order to differentiate the two, we put them in a namespace (foo and bar) so mine can be called by foo.baz() and Joe's can be called by bar.baz().
Of course, typing foo.baz() all the time gets annoying if you just want baz() and are sure that none of your other modules imported will provide any problems... That is why python provides the from foo import * syntax, or even from foo import baz to only import the function/object/constant baz (as others have already noted).
Note that things can get even more complex:
Assume you have a module foo which provides function bar and baz, below are a few ways to import and then call the functions contained inside foo...
import foo # >>> foo.bar();foo.baz()
import foo as bar # >>> bar.bar();bar.baz()
from foo import bar,baz # >>> bar(); baz()
from foo import * # >>> bar(); baz()
from foo import bar as cow # >>> cow() # This calls bar(), baz() is not available
...
A basic import statement is an assignment of the module object (everything's an object in Python) to the specified name. I mean this literally: you can use an import anywhere in your program you can assign a value to a variable, because they're the same thing. Behind the scenes, Python is calling a built-in function called __import__() to do the import, then returning the result and assigning it to the variable name you provided.
import foo
means "import module foo and assign it the name foo in my namespace. This is the same as:
foo = __import__("foo")
Similarly, you can do:
import foo as f
which means "import module foo and assign it the name f in my namespace." This is the same as:
f = __import__("foo")
Since in this case, you have only a reference to the module object, referring to things contained by the module requires attribute access: foo.bar etc.
You can also do from foo import bar. This creates a variable named bar in your namespace that points to the bar function in the foo module. It's syntactic sugar for:
bar = __import__("foo").bar
I don't really understand your confusion. You've imported the name my_file, not anything underneath it, so that's how you reference it.
If you want to import functions or classes inside a module directly, you can use:
from my_file import function
I'm going to incorporate many of the comments already posted.
To have access to function without having to refer to the module my_file, you can do one of the following:
from my_file import function
or
from my_file import *
For a more in-depth description of how modules work, I would refer to the documentation on python modules.
The first is the preferred solution, and the second is not recommended for many reasons:
It pollutes your namespace
It is not a good practice for maintainability (it becomes more difficult to find where specific names reside.
You typically don't know exactly what is imported
You can't use tools such as pyflakes to statically detect errors in your code
Python imports work differently than the #includes/imports in a static language like C or Java, in that python executes the statements in a module. Thus if two modules need to import a specific name (or *) out of each other, you can run into circular referencing problems, such as an ImportError when importing a specific name, or simply not getting the expected names defined (in the case you from ... import *). When you don't request specific names, you don't run into the, risk of having circular references, as long as the name is defined by the time you actually want to use it.
The from ... import * also doesn't guarantee you get everything. As stated in the documentation on python modules, a module can defined the __all__ name, and cause from ... import * statements to miss importing all of the subpackages, except those listed by __all__.
Suppose I have a package named bar, and it contains bar.py:
a = None
def foobar():
print a
and __init__.py:
from bar import a, foobar
Then I execute this script:
import bar
print bar.a
bar.a = 1
print bar.a
bar.foobar()
Here's what I expect:
None
1
1
Here's what I get:
None
1
None
Can anyone explain my misconception?
You are using from bar import a. a becomes a symbol in the global scope of the importing module (or whatever scope the import statement occurs in).
When you assign a new value to a, you are just changing which value a points too, not the actual value. Try to import bar.py directly with import bar in __init__.py and conduct your experiment there by setting bar.a = 1. This way, you will actually be modifying bar.__dict__['a'] which is the 'real' value of a in this context.
It's a little convoluted with three layers but bar.a = 1 changes the value of a in the module called bar that is actually derived from __init__.py. It does not change the value of a that foobar sees because foobar lives in the actual file bar.py. You could set bar.bar.a if you wanted to change that.
This is one of the dangers of using the from foo import bar form of the import statement: it splits bar into two symbols, one visible globally from within foo which starts off pointing to the original value and a different symbol visible in the scope where the import statement is executed. Changing a where a symbol points doesn't change the value that it pointed too.
This sort of stuff is a killer when trying to reload a module from the interactive interpreter.
One source of difficulty with this question is that you have a program named bar/bar.py: import bar imports either bar/__init__.py or bar/bar.py, depending on where it is done, which makes it a little cumbersome to track which a is bar.a.
Here is how it works:
The key to understanding what happens is to realize that in your __init__.py,
from bar import a
in effect does something like
a = bar.a
# … where bar = bar/bar.py (as if bar were imported locally from __init__.py)
and defines a new variable (bar/__init__.py:a, if you wish). Thus, your from bar import a in __init__.py binds name bar/__init__.py:a to the original bar.py:a object (None). This is why you can do from bar import a as a2 in __init__.py: in this case, it is clear that you have both bar/bar.py:a and a distinct variable name bar/__init__.py:a2 (in your case, the names of the two variables just happen to both be a, but they still live in different namespaces: in __init__.py, they are bar.a and a).
Now, when you do
import bar
print bar.a
you are accessing variable bar/__init__.py:a (since import bar imports your bar/__init__.py). This is the variable you modify (to 1). You are not touching the contents of variable bar/bar.py:a. So when you subsequently do
bar.foobar()
you call bar/bar.py:foobar(), which accesses variable a from bar/bar.py, which is still None (when foobar() is defined, it binds variable names once and for all, so the a in bar.py is bar.py:a, not any other a variable defined in another module—as there might be many a variables in all the imported modules). Hence the last None output.
Conclusion: it is best to avoid any ambiguity in import bar, by not having any bar/bar.py module (since bar.__init__.py makes directory bar/ a package already, that you can also import with import bar).
To put another way:
Turns out this misconception is very easy to make.
It is sneakily defined in the Python language reference: the use of object instead of symbol. I would suggest that the Python language reference make this more clear and less sparse..
The from form does not bind the module name: it goes through the
list of identifiers, looks each one of them up in the module found in
step (1), and binds the name in the local namespace to the object thus
found.
HOWEVER:
When you import, you import the current value of the imported symbol and add it to your namespace as defined. You are not importing a reference, you are effectively importing a value.
Thus, to get the updated value of i, you must import a variable that holds a reference to that symbol.
In other words, importing is NOT like an import in JAVA, external declaration in C/C++ or even a use clause in PERL.
Rather, the following statement in Python:
from some_other_module import a as x
is more like the following code in K&R C:
extern int a; /* import from the EXTERN file */
int x = a;
(caveat: in the Python case, "a" and "x" are essentially a reference to the actual value: you're not copying the INT, you're copying the reference address)