module naming conventions

[grackle]

Obviously Java-style naming is a mistake in Python, since top-level
names have to be unique.  Is there a standard naming convention to
facilitate mixing code from different sources, such as
mygroupname_modulename?  Is there a best practices guide for module
naming?

Thanks,
David
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: module naming conventions

[grackle]

On Jan 14, 4:47 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> I'm not sure, but it sounds as though you have yet to discover Python
> module packages 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.  There's still a
chance of accidental name clashes with other developers in my company,
but those can be dealt with.  I'm not forced to share a top-level
module with every other Python project in the company, so I can
develop different projects independently and then import one into the
other, without modifying or merging their source.

Of course, the best convention is probably the predominant one, and
that's my question:  What is the standard way of naming Python
packages?

-David
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: module naming conventions

[grackle]

On Jan 14, 6:28 pm, Ben Finney <[EMAIL PROTECTED]>
wrote:
> grackle <[EMAIL PROTECTED]> writes:
> What do you mean by "top-level module", and "the same top-level name"?
> Do you mean "the same fully-qualified name"? If two modules are in
> separate places in the hierarchy, they will have different
> fully-qualified names.

I mean that if I worked at Google (which I don't) and developed
google.search and google.officeapps, they would share the same top-
level name "google".  Because of this, if I wanted to use the two in
the same program, they would have to be deployed at the same point in
the source path:  if I deployed one set of source at src1/google/
search/etc. and the other at src2/google/officeapps/etc. and added
src1/ and src2/ to my application's Python source path, one of them
would be found and the other not.  (Essentially I'd be trying to
create two different modules, both named "google", which is
nonsense.)  I would have to put them in the same source directory and
merge the two google/__init__.py files together.

I might as well admit that I already made the same mistake in reverse,
using a single top-level module for my application, which I now want
to split into a group of core application modules and one or more
optional, separately-deployed packages.  Since I screwed up the first
time, I figured I'd get advice before attempting to rectify the
situation.  My next (slightly more considered, possibly just as naive)
impulse is to turn google.search and google.officeapps into
google_search and google_officeapps, thereby avoiding name clashes
with internal or external projects.  (It feels dangerous, not to
mention presumptuous, to put generic names like "search" and
"officeapps" in the global namespace.)

> Release your package as free software on the Cheeseshop
> http://cheeseshop.python.org/>. If the name you want is already
> taken, pick one that will help users distinguish yours from the
> existing one.

Unfortunately, my company thinks it's their software and not mine :-)

-David
-- 
http://mail.python.org/mailman/listinfo/python-list