Opinions, please, on PEP 8 and local, 3rd party imports

[Ben Finney]

Philip Semanchuk <philip at semanchuk.com> writes:

> Our project uses some libraries that were written by 3rd parties (i.e.
> not us). These libraries fit into a single Python file and live in our
> source tree alongside other modules we've written.

Why in the same source tree? They are maintained separately, so you
shouldn't be duplicating them in your source.

> When our app is distributed, they'll be included in the installation.

That can be done simply by having the third-party's standard
distribution included with yours, and use it *if it's not already
installed* on the user's system.

> In other words, they're not prerequisites that we'll make the user
> install, and they won't live in site-packages.

What if they already *do* exist in site-packages? Why not install them
there yourself?

> PEP 8 <http://www.python.org/dev/peps/pep-0008/> says the following:
>
>    Imports should be grouped in the following order:
>    1. standard library imports
>    2. related third party imports
>    3. local application/library specific imports
>
>
> I'm not sure in which category to place local, 3rd-party modules like
> configobj.

They are third-party imports; category 2.

> Clearly, they belong in category 3 since they're local.

They shouldn't be local, since they're not part of your application's
code base; they're maintained as separate distributions (even if you
bundle them together when distributing your work).

Moreover, if there is an update to configobj by its current maintainers,
and I have installed three (or seven, or seventy-three) applications
using it, I want *one* update into site-packages to fix it for *all* of
those applications. Not have to fuss about with all the duplicated
copies, and worry about which ones have been missed (or, worse, *not*
worry and the be confused over why the bug is still occurring in some
applications).

> Clearly, they also belong in category 2 since they're 3rd party
> modules, and explicitly labeling an imported module as "this is code
> we didn't write" is useful. But I've always reserved category 2 for
> external libraries (e.g. numpy, wxPython, Twisted, PIL, etc.).

Third-party libraries *are* external libraries. Please, for the sake of
your users, keep them so. You can *install* them at the same time, but
please don't *duplicate* them, forking them as though they're part of
your code base.

-- 
 \     “We are not gonna be great; we are not gonna be amazing; we are |
  `\           gonna be *amazingly* amazing!” —Zaphod Beeblebrox, _The |
_o__)                Hitch-Hiker's Guide To The Galaxy_, Douglas Adams |
Ben Finney