Information in this section is taken from this document.
The primary use of init.py is to initialize Python packages. The inclusion of the init.py file in a directory indicates to the Python interpreter that the directory should be treated like a Python package.
init_.py can be an empty file but it is often used to perform setup needed for the package(import things, load things into path, etc).
One common thing to do in your init.py is to import selected Classes, functions, etc into the package level so they can be convieniently imported from the package.
In our example above we can say that file.py has the Class File. So without anything in our init.py you would import with this syntax:
from package.file import File
However you can import File into your init.py to make it available at the package level:
# in your __init__.py from file import File # now import File from package from package import File
Another thing to do is at the package level make subpackages/modules available with the all variable. When the interpeter sees an all variable defined in an init.py it imports the modules listed in the all variable when you do:
from package import *
all is a list containing the names of modules that you want to be imported with import * so looking at our above example again if we wanted to import the submodules in subpackage the all variable in subpackage/__init__.py would be:
__all__ = ['submodule1', 'submodule2']
With the all variable populated like that, when you perform
from subpackage import *
it would import submodule1 and submodule2.
See https://docs.python.org/3.0/whatsnew/3.0.html for specific information. Here's a list of changes that have affected me:
- Python 3 stores strings as Unicode by default, whereas Python 2 requires you to mark a string with a “u” if you want to store it as Unicode.
range()now behaves like
xrange()used to behave, except it works with values of arbitrary size. The latter no longer exists.
- An expression like
1/2returns a float. Use
1//2to get the truncating behavior.
- Extended Iterable Unpacking. You can now write things like
a, b, *rest = some_sequence. And even
*rest, a = stuff. The rest object is always a (possibly empty) list; the right-hand side may be any iterable. Example:
(a, *rest, b) = range(5). This sets This sets
4, and rest to
[1, 2, 3].
- Dictionary comprehensions
- Set literals. Set comprehensions are also supported.
Python 3.6 also adds formatted string literals or f-strings. See this page.
Information in this section is taken from the virtualenv docs.
virtualenv "creates an environment that has its own installation
directories, that doesn't share libraries with other virtual env
environments (and optionally doesn't access the globally installed
libraries either)." An example of a time this utility is useful is
when you have two applications that use different versions of a
Virtualenv has one basic command:
$ virtualenv ENV
ENV is a directory to place the new virtual
environment. This directory is often called
venv (so we would run
virtualenv venv. This command has a number of usual effects:
ENV/include/are created, containing supporting library files for a new virtualenv python. Packages installed in this environment will live under
ENV/binis created, where executables live - noticeably a new python. Thus running a script with
#! /path/to/ENV/bin/pythonwould run that script under this virtualenv’s python.
- The crucial packages pip and setuptools are installed, which
allow other packages to be easily installed to the
environment. This associated pip can be run from
The python in your new virtualenv is effectively isolated from the python that was used to create it.
In the newly created virtualenv there will also be an activate
shell script. On mac machines, this script can be called with
. ENV/bin/activate. where again
ENV is the name of the
virtualenv directory (again, often
This will change your
$PATH so its first entry is the
bin/ directory. This is all it does; it's purely a
convenience. If you directly run a script or the python
interpreter form the virtual env's
bin/ directory there's no
need for activation.
activate script will also modify your shell prompt to
indicate which environment is currently active.
To undo these changes to your path (and prompt), just run:
Removing an Environment
Removing a virtual environment is simply done by deactivating it and deleting the environment folder with all its contents:
(ENV)$ deactivate $ rm -r /path/to/ENV
If you build with
virtualenv --system-site-packages ENV, your
virtual environment will inherit packages from
/usr/lib/python2.7/site-packages (or wherever your global
site-packages directory is).
This can be used if you have control over the global site-packages directory, and you want to depend on the packages there. If you want isolation from the global system, do not use this flag.