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