Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am developing a Python App Engine app, where I want to split the content of a source code file Models.py into separate files for each model, but I want to put it all in a folder called Models. The problem is that when I do that, my app can't find the classes anymore. What should I do?
This question is not about MVC but another question with the same title is.
Put an empty __init__.py file in the Models directory.
Then, in your app; presumably one level up, you reference modules in the Models directory like this:
import Models
and do something with it like this:
Models.my_model.MyClassName
You can also use the from keyword like this:
from Models import my_model
and reference like this:
my_model.MyClassName
If you only need one method from a module, you could also do this:
from Models.my_model import my_method_name
my_method_name()
Obligatory link to the documentation.
In response to your comment to Adam's answer, regarding having 10 imports for 10 classes, firstly don't forget that there's no need to have one class per module in Python. Modules should be organised by functionality, so you can group related classes in a single file if that makes sense.
If you still wanted to make all the classes importable in one go, you could import them all in the __init__.py file itself using the from submodule import Class syntax, then just import the containing module - import mainmodule and refer to mainmodule.Class1 etc, or even use from mainmodule import Class1, Class2, Class3 to import the classes directly into your namespace and refer to them directly.
Adam Bernier provides a good technical description of how packages work. A great description of how to arrange and ship a project is described in http://jcalderone.livejournal.com/39794.html
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I am learning Python and feel import function is some different from that of Java.
I have a code hierarchy like below:
./test.py
import pack
./pack/__init__.py
from . import submod
./pack/submod.py
from .anothersubmod import res
./pack/anothersubmod.py
res="something..."
test.py runs as above. When I re-write submod.py as:
from anothersubmod import res
Python gives me an error saying anothersubmod can not be found...
I guess submod and anothersubmod are in same directory thus they shall refer to each other with their module (file) name, why should I have to add a dot before anothersubmod?
The Java equivalent would be to explicitly reference pack everywhere, like:
import pack.anothersubmod.MyClass;
The Python equivalent of that would be:
from pack.anothersubmod import MyClass
That is correct Python and actually preferred style. Python also has the ability to use relative paths in import statements (from . style), but they tend to cause more confusion.
PEP 8 recommends using absolute imports everywhere whenever possible:
Absolute imports are recommended, as they are usually more readable and tend to be better behaved (or at least give better error messages) if the import system is incorrectly configured.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I see in PEP8 that the accepted best practice for importing is to put all imports at the top of the module. I am wondering if this is still the case if you want to have multiple subclasses with different import needs all inside the same module.
Specifically, I am making a generic DataConnector class to read data from different sources and then put that data into a pandas dataframe. I will have subclasses that read the different sources of data. For instance, one subclass will be CsvConnector(DataConnector), another PGdatabaseConnector(DataConnector). The Csv subclass will need to import csv and the PGdatabase class will need to import psycopg2. Is the best practice still to keep all the imports at the top of the entire module?
(Logically it seem that all the classes should be contained in one module, but I could also see putting them all in different modules and then I wouldn't have to worry about importing libraries that wouldn't be used.)
There are occasional cases where you'd want to put imports elsewhere (such as when imports have side-effects that you need to invoke in a certain order), but in this case, all your imports should go at the top of the .py source file like a table of contents. If you feel like your file is getting too cluttered, break out each class and the relevant imports into new source files.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Sorry if the title is confusing.
What I am trying to say is this:
I have worked with Python before, but I'm by no means an expert. So far everything I have done has just been 'somefile.py' with lots of methods and code in it, but it doesn't really have any organizational structure. In Java (which I am more familiar with than Python), there are usually different classes that each have methods and are called from each other. How do you make a file full of code organized and structured when working on a large project? Break them up into files by class?
Hopefully this is clearer. Let me know if this needs clarification.
In Python, the file unit is called module. Modules are organized in packages.
You usually put your classes each in a module and also use modules to group related code that doesn't belong to any class. Related modules are grouped in packages (physically represented by directories) which effectively create namespaces.
Then you use the import command to import the desired pieces of the code into other modules.
You can read about modules, packages and import in the Python documentation here.
Logically, it isn't much different than Java or other languages.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm not familiar with other languages, so I don't know if they do this (or similar) as well (and am curious).
For example, why do I write:
from pylearn2.utils import serial
instead of
from pylearn2/utils import serial
???
Because Python sees packages and modules as objects, and thus uses dot-notation to access their "attributes".
More on package objects and their notation:
From Guido, himself – http://www.network-theory.co.uk/docs/pytut/Packages.html
From the Python docs – https://docs.python.org/2/tutorial/modules.html
And here's some proof in importing the Django package:
>>> import django
>>> type(django)
<type 'module'>
>>> type(django.contrib.auth.models)
<type 'module'>
A vast majority of programming languages use dots/periods for namespace references. The only one that I personally know that doesn't is PHP.
VB:
Imports System.Text
Imports System.IO
Imports Microsoft.VisualBasic.ControlChars
C#:
using System;
using System.Web.Services.Description;
using System.Collections;
using System.Xml;
Java:
import javax.swing.*;
ActionScript 3:
import flash.display.Sprite;
import flash.display.Shape;
import flash.events.MouseEvent;
import flash.filters.DropShadowFilter;
PHP:
use PhpAmqpLib\Connection\AMQPConnection;
use PhpAmqpLib\Message\AMQPMessage;
In addition to other answers...
Not all modules are in the file system in the way they are defined on import. That somepackage.somemodule happens to be on the disk at somepackage/somemodule.py is only one way to do it. A C extention, for instance, may be sitting in a different place or with a different name. Also, some modules like to play with their namespaces. 'os.path' may really be 'ntpath' or 'posixpath'.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
This is a language design question. Why the designer didn't use
import A.B
instead of
from A import B
assuming A is a module that contains function B. Isn't it better to have a single style for import syntax? What was the design principle behind this? I think that the Java style import syntax feels more natural.
Python import statements primarily exist to load modules and packages. You have to import a module before you can use it. The second form of import is merely an additional feature, loading the module and then copying some parts of it into the local namespace.
Java import statements exist to make shortcuts to names loaded in other modules. Java import statements don't load anything, but merely move things into the local namespace. In Java you don't need to import modules in order to use them. The import statement has nothing to do with whether or not a module is loaded.
So the two languages take quite a different approach to importing. The imports statements are basically just not doing the same thing. Python's imports are for loading and Java imports are for shortcuts.
Java's approach would be somewhat problematic in python. In Java it's pretty easy to sort of what's a class/module/package from the syntax. Python does not have that advantage. As a result, the compiler and the reader would have difficulty determing what is and isn't meant to be a reference to an external package. For that reason, Python's designer chose to make it explicit and force you to specify which external module you want to load.
Consistency. import A.B never adds B to the local namespace, even for cases in which it is valid; it simply makes B available via A, which functions already naturally are.
You can do this with modules, but not functions, eg.
os.path is commonly imported like that