Philip Semanchuk wrote:
Hi all,
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. When our app is
distributed, they'll be included in the installation. In other words,
they're not prerequisites that we'll make the user install, and they
won't live in site-packages.
For example, we use configobj from
<http://www.voidspace.org.uk/downloads/configobj.py>, and I think
Beautiful Soup can be installed as a single file too, although we're
not using that particular module.
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.
Clearly, they belong in category 3 since they're local.
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.).
Clearly, the best choice is category 2.5?
In your Pythonic opinion, should 3rd-party modules that live alongside
homegrown code be listed in import category 2 or 3?
Thanks
Philip
--http://mail.python.org/mailman/listinfo/python-list
Since you provide a local file, this could be considered from a QA point
of view as an uncontrolled version of the standard library. So it's no
more standard, could be then considered as local.
I'm not sure it is *that* import though.
JM
--
http://mail.python.org/mailman/listinfo/python-list
