Opinions, please, on PEP 8 and local, 3rd party imports
Ben Finney
ben+python at benfinney.id.au
Sat Oct 3 02:35:58 EDT 2009
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
More information about the Python-list
mailing list