module naming conventions
Jorgen Grahn
grahn+nntp at snipabacken.dyndns.org
Thu Jan 17 04:56:23 EST 2008
On Mon, 14 Jan 2008 15:58:49 -0800 (PST), grackle <davidhuebel at gmail.com> wrote:
> On Jan 14, 4:47 pm, Ben Finney <bignose+hates-s... at benfinney.id.au>
> wrote:
>> I'm not sure, but it sounds as though you have yet to discover Python
>> module packages <URL:http://www.python.org/doc/essays/packages.html>.
>> They allow a hierarchy of modules in directories.
>
> I do use packages. I mentioned the Java naming conventions because
> they were my first thought for solving the problem of name clashes,
> and they work well in some non-Java languages. They don't apply well
> to Python, since every top-level module has a unique identity that can
> only be specified on one source path. If two libraries use the same
> top-level module name, they can't be used together in the same program
> without modifying their source code.
>
> mycompany_mymodulename was just the first solution I thought of that
> seemed practical. The mycompany_ prefix protects me from name clashes
> with useful modules I might acquire from elsewhere.
Seems to me that the Python community solves this as if you had
released an executable program for Unix (where all executables end up
in /usr/bin or /usr/local/bin, so they have to have unique names).
In Linux, I am aware of very few name clashes. People tend to know
what names are used and pick other ones. A suite of executables
usually share a common prefix (like packages in Python).
Some names are a bit far-fetched or silly, of course, but in practice
it works reasonably well.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
More information about the Python-list
mailing list