Python

__init__.py

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.

Python 3

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.
  • The print statement has been replaced with the print() function.
  • 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/2 returns a float. Use 1//2 to 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 a to 0, b to 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.

Virtualenv

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 certain library.

Usage

Virtualenv has one basic command:

$ virtualenv ENV

Where 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/lib/ and ENV/include/ are created, containing supporting library files for a new virtualenv python. Packages installed in this environment will live under ENV/lib/pythonX.X/site-packages/.
  • ENV/bin is created, where executables live - noticeably a new python. Thus running a script with #! /path/to/ENV/bin/python would 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 ENV/bin/pip.

The python in your new virtualenv is effectively isolated from the python that was used to create it.

Activate Script

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 venv).

This will change your $PATH so its first entry is the virtualenv's 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.

The 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:

$ deactivate

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

The --system-site-packages Option

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.