Differences between revisions 1 and 2
Revision 1 as of 2014-01-11 22:24:32
Size: 7495
Editor: LutzPrechelt
Comment:
Revision 2 as of 2014-01-12 15:21:48
Size: 7628
Editor: LutzPrechelt
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
This page assumes
Line 3: Line 4:
This page assumes
Line 11: Line 11:
Line 18: Line 19:
''Disclaimer:'' The primary author of this page is a Python intermediate himself.
If an expert could check/correct the statements and then remove this message, that would be most helpful.
If this message is still present, beware of errors.
''Disclaimer:'' The primary author of this page is a Python intermediate himself. If an expert could check/correct the statements and then remove this message, that would be most helpful. If this message is still present, beware of errors.
Line 25: Line 24:
== Python3 versus Python2 ==
Python3 is mature enough and well-supported enough that you could consider it the preferred platform when you write software from scratch.
Line 26: Line 27:
== Python3 versus Python2 ==

Python3 is mature enough and well-supported enough that you could consider it the preferred
platform when you write software from scratch
.

The main reason for using Python2 is that you work with an existing Python2 software base.
A secondary reason could be that an extension package that will be important for you is available for Python2 only.
(But there are now also packages that are available in Python3 only)
The main reason for using Python2 is that you work with an existing Python2 software base. A secondary reason could be that an extension package that will be important for you is available for Python2 only. (But there are now also packages that are available in Python3 only)
Line 37: Line 30:
Line 41: Line 33:
== Multiple isolated Python environments ==
By default, packages are installed ''into'' the local Python installation. They become a part of it and will be available to any Python program on that computer. This can become inconvenient: Sometimes you need different versions of a package for different applications or a certain package must ''not'' be available for some.
Line 42: Line 36:
== Multiple isolated Python environments == One could avoid this by installing packages elsewhere and manipulating the {{{PYTHONPATH}}} environment variable appropriately, but this is inconvenient as well, because packages often depend on many other packages and so this approach can produce immense confustion and giant {{{PYTHONPATH}}} lists.
Line 44: Line 38:
By default, packages are installed ''into'' the local Python installation.
They become a part of it and will be available to any Python program on that computer.
This can become inconvenient: Sometimes you need different versions of a package
for different applications or a certain package must ''not'' be available for some.

One could avoid this by installing packages elsewhere and manipulating the {{{PYTHONPATH}}}
environment variable appropriately, but this is inconvenient as well, because packages
often depend on many other packages and so this approach can produce immense confustion
and giant {{{PYTHONPATH}}} lists.

A ''virtual environment'' behaves like a copy of the Python installation's
directory tree (with or without the {{{site-packages}}} subtree).
One can have a separate virtual environment for each project or application
to isolate them from each other and install only the required packages into each.
A ''virtual environment'' behaves like a copy of the Python installation's directory tree (with or without the {{{site-packages}}} subtree). One can have a separate virtual environment for each project or application to isolate them from each other and install only the required packages into each.
Line 62: Line 43:
You should use a virtual environment for any team project and for any package
you intend to distribute.
You should use a virtual environment for any team project and for any package you intend to distribute.
Line 67: Line 46:
Since Python 2.0, there is a convention that any reusable package or distributable application should have a top level file {{{setup.py}}} that implements a command line tool for installation and configuration. This file will
Line 68: Line 48:
Since Python 2.0, there is a convention that any reusable package
or distributable application should have a top level file
{{{setup.py}}} that implements a command line tool for installation
and configuration. This file will
 
* declare the metadata of the package (name, version, etc.)
  * declare the constituent parts of the package (pure Python modules,
    extension modules in some other language, data files, etc.)
  * declare the dependencies of the package:
    other python packages that must be installed (and the required versions)
   
and other binary libraries required for linking the extension
   
modules after those have been compiled
 * declare the metadata of the package (name, version, etc.)
 * declare the constituent parts of the package (pure Python modules,
  . extension modules in some other language, data files, etc.)
 * declare the dependencies of the package:
  . other python packages that must be installed (and the required versions) and other binary libraries required for linking the extension modules after those have been compiled
Line 80: Line 54:
See the documentation of [[http://docs.python.org/3/distutils/|distutils]] from the standard library.
Distutils will not only make {{{setup.py}}} easy to write,
it will also provide it with functionality for ''creating'' the distributable package file
in the first place.
See the documentation of [[http://docs.python.org/3/distutils/|distutils]] from the standard library. Distutils will not only make {{{setup.py}}} easy to write, it will also provide it with functionality for ''creating'' the distributable package file in the first place.
Line 85: Line 56:
In contrast to some other platforms it is common in Python that neither a reusable
package nor a distributable application come packaged with all the additional
reusable packages they depend on.
Rather, the dependencies are only ''declared'' in {{{setup.py}}} and
an installer program such as [[http://www.pip-installer.org|pip]]
will download and install additional packages (that are yet missing
or the version of which is inappropriate) automatically.
In contrast to some other platforms it is common in Python that neither a reusable package nor a distributable application come packaged with all the additional reusable packages they depend on. Rather, the dependencies are only ''declared'' in {{{setup.py}}} and  an installer program such as [[http://www.pip-installer.org|pip]] will download and install additional packages (that are yet missing or the version of which is inappropriate) automatically.
Line 93: Line 58:
Confusingly, there are multiple frameworks that are used to support
{{{setup.py}}}:
Confusingly, there are multiple frameworks that are used to support {{{setup.py}}}:
Line 103: Line 68:
So what should you use?
For an up-to-date answer, see the [[http://stackoverflow.com/questions/6344076/differences-between-distribute-distutils-setuptools-and-distutils2|summary on stackoverflow]] and the [[https://python-packaging-user-guide.readthedocs.org|Python Packaging User Guide recommendation]].
So what should you use? First, be aware that many packages on PyPI will {{{import setuptools}, so you need to have {{{setuptools}}} or {{{distribute}}} installed in any case. Second, for an up-to-date answer for your own development, see the [[http://stackoverflow.com/questions/6344076/differences-between-distribute-distutils-setuptools-and-distutils2|summary on stackoverflow]] and the [[https://python-packaging-user-guide.readthedocs.org|Python Packaging User Guide recommendation]].
Line 108: Line 71:
There is a surprising range of toolkits for building desktop GUIs with Python. One of them, [[http://docs.python.org/3/library/tkinter.html|tkinter]], is a core package consisting of Python bindings for TCL/TK's tk plus additional widgets (in [[http://docs.python.org/3/library/tkinter.ttk.html|tkinter.ttk]] and [[http://docs.python.org/3/library/tkinter.tix.html|tkinter.tix]]). tkinter is platform-independent and easy to program for simple GUIs.
Line 109: Line 73:
There is a surprising range of toolkits for building desktop GUIs with Python.
One of them,
[[http://docs.python.org/3/library/tkinter.html|tkinter]],
is a core package consisting of Python bindings for TCL/TK's tk plus additional widgets (in
[[http://docs.python.org/3/library/tkinter.ttk.html|tkinter.ttk]] and
[[http://docs.python.org/3/library/tkinter.tix.html|tkinter.tix]]).
tkinter is platform-independent and easy to program for simple GUIs.

For larger applications, you might prefer a more extensive GUI toolkit.
For larger applications, you might prefer [[GuiProgramming|a more extensive GUI toolkit]].
Line 121: Line 76:

There is a surprising range of frameworks for building web applications with Python.
Several of them are quite good.
They follow fairly different objectives (such as being slim vs. extensive
or regarding the development style they imply).
Among these, [[https://www.djangoproject.com/|Django]] has the largest and most active
community by far.
There is a surprising range of frameworks for building web applications with Python. Several of them are quite good. They follow fairly different objectives (such as being slim vs. extensive or regarding the development style they imply). Among these, [[https://www.djangoproject.com/|Django]] has the largest and most active community by far.
Line 131: Line 79:
There are at least two mature, powerful, and widely used solutions for O/R mapping:
Line 132: Line 81:
There are two mature, powerful, and widely used solutions for O/R mapping:
Line 136: Line 84:
Although Django is a web development framework, some people also use it for
non-web software in order to make use of its persistence framework.

Although Django is a web development framework, some people also use it for non-web software in order to make use of its persistence framework.

The Python intermediate's guide: Python packages confusion reducer

This page assumes

  • that you are an experienced software developer, but fairly new to Python,
  • that you have mastered enough of Python's language constructs and standard library ("core packages") to have ventured beyond these into the wider world of Python extension packages, and

  • that you were confused by what you found.

The aim of this page is to reduce this confusion in a few important spots.

Some recurring sources of such confusion are these:

  • Outdated information on Q&A sites (Python has a long history!)

  • Python2 vs. Python3 differences

  • Many packages have names different from that of the namespace you will import when you use them

  • Some closely related packages have widely different names
  • Too many packages to choose from for the same purpose
  • Understatement: Many packages with zero-point-something version numbers have been stable and mature for years

Disclaimer: The primary author of this page is a Python intermediate himself. If an expert could check/correct the statements and then remove this message, that would be most helpful. If this message is still present, beware of errors.


Python3 versus Python2

Python3 is mature enough and well-supported enough that you could consider it the preferred platform when you write software from scratch.

The main reason for using Python2 is that you work with an existing Python2 software base. A secondary reason could be that an extension package that will be important for you is available for Python2 only. (But there are now also packages that are available in Python3 only)

Package installation

  • PyPI is for Python what CPAN is for Perl and what CTAN is for TeX: an almost comprehensive catalog of the freely available reusable components.

  • For downloading and installing PyPI packages and keeping a set of such installations up to date, pip is far more powerful than easy_install and should almost always be preferred.

Multiple isolated Python environments

By default, packages are installed into the local Python installation. They become a part of it and will be available to any Python program on that computer. This can become inconvenient: Sometimes you need different versions of a package for different applications or a certain package must not be available for some.

One could avoid this by installing packages elsewhere and manipulating the PYTHONPATH environment variable appropriately, but this is inconvenient as well, because packages often depend on many other packages and so this approach can produce immense confustion and giant PYTHONPATH lists.

A virtual environment behaves like a copy of the Python installation's directory tree (with or without the site-packages subtree). One can have a separate virtual environment for each project or application to isolate them from each other and install only the required packages into each.

  • virtualenv implements virtual environments for Python2

  • venv implements virtual environments for Python3. It is a core package and technically subtly superior to virtualenv.

You should use a virtual environment for any team project and for any package you intend to distribute.

Creating a package installer or application installer

Since Python 2.0, there is a convention that any reusable package or distributable application should have a top level file setup.py that implements a command line tool for installation and configuration. This file will

  • declare the metadata of the package (name, version, etc.)
  • declare the constituent parts of the package (pure Python modules,
    • extension modules in some other language, data files, etc.)
  • declare the dependencies of the package:
    • other python packages that must be installed (and the required versions) and other binary libraries required for linking the extension modules after those have been compiled

See the documentation of distutils from the standard library. Distutils will not only make setup.py easy to write, it will also provide it with functionality for creating the distributable package file in the first place.

In contrast to some other platforms it is common in Python that neither a reusable package nor a distributable application come packaged with all the additional reusable packages they depend on. Rather, the dependencies are only declared in setup.py and an installer program such as pip will download and install additional packages (that are yet missing or the version of which is inappropriate) automatically.

Confusingly, there are multiple frameworks that are used to support setup.py:

  • distutils is a core package (i.e., part of the standard library). Usage: import distutils

  • setuptools is an extension package to extend distutils. Usage: import setuptools

  • distribute was forked off the setuptools project. Usage is also import setuptools

  • distutils2 was forked off the distribute project (by the same team) with the intention to create what could eventually become a new core package, but was later abandoned.

  • distribute was merged back into setuptools.

  • distlib is an alternative attempt towards a new core package.

  • bento is an independent alternative framework.

So what should you use? First, be aware that many packages on PyPI will import setuptools}, so you need to have {{{setuptools or distribute installed in any case. Second, for an up-to-date answer for your own development, see the summary on stackoverflow and the Python Packaging User Guide recommendation.

GUI programming

There is a surprising range of toolkits for building desktop GUIs with Python. One of them, tkinter, is a core package consisting of Python bindings for TCL/TK's tk plus additional widgets (in tkinter.ttk and tkinter.tix). tkinter is platform-independent and easy to program for simple GUIs.

For larger applications, you might prefer a more extensive GUI toolkit.

Web development

There is a surprising range of frameworks for building web applications with Python. Several of them are quite good. They follow fairly different objectives (such as being slim vs. extensive or regarding the development style they imply). Among these, Django has the largest and most active community by far.

Object-relational mapping

There are at least two mature, powerful, and widely used solutions for O/R mapping:

Although Django is a web development framework, some people also use it for non-web software in order to make use of its persistence framework.

IntermediatesGuide (last edited 2019-10-27 00:31:30 by JennyRyan)

Unable to edit the page? See the FrontPage for instructions.