module naming conventions

[Ben Finney]

grackle <davidhuebel at gmail.com> writes:

> 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.

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.

=====
$ find foo/ -name '*.py'
foo/__init__.py
foo/spam.py
foo/bar/__init__.py
foo/bar/spam.py
foo/baz/__init__.py
foo/baz/spam.py
=====

===== eggs.py =====
import foo.spam
import foo.bar.spam
import foo.baz.spam

# ...
=====

> 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.

Ah, I see; you're referring to a worldwide package namespace, enforced
by the language. AFAIK there's no such thing in Python.

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

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

-- 
 \           "If you do not trust the source do not use this program." |
  `\                                —Microsoft Vista security dialogue |
_o__)                                                                  |
Ben Finney