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

 

[Ben Finney]

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?

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.

The Python tutorial <URL:http://www.python.org/doc/tut/> will make
this and many more fundamental concepts of Python clearer by working
through it. Read each section, run every example, and experiment with
it until you understand it. Then move on to the next section. Repeat
until done.

 

[grackle]

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

 

[Ben Finney]

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.

 

[Carl Banks]

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?

Not really. Try to pick a unique name for your project. <:\


Carl Banks

 

[grackle]

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

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

-David

 

[Ben Finney]

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

That's fine. Companies can release (and sell!) freely-licensed
software too, and many of them do so. You, as someone who works there
and is presumably responsible for this package, have leverage more
than anyone else in this discussion to make it happen.

 

[Tobiah]

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.

I like this idea. I developed a library with a name that got
a couple of obscure software related hits on Google. I checked
sourceforge, and found that the name was available, so I stuck
my flag in the dirt.

It was a python module, so I suppose I will have to look into
the cheeseshop. Is that as open as sourceforge, or is it only
for mature, sophisticated modules?

Thanks,

Tobiah

 

[Terry Reedy]

|
| > 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.
| >
|
| I like this idea. I developed a library with a name that got
| a couple of obscure software related hits on Google. I checked
| sourceforge, and found that the name was available, so I stuck
| my flag in the dirt.
|
| It was a python module, so I suppose I will have to look into
| the cheeseshop. Is that as open as sourceforge, or is it only
| for mature, sophisticated modules?

Look at the cheeseshop page, but I would say that 'mature' and
'sophisticated' are too high a bar. 'Potentially useful and
not-known-to-be-buggy'
should be more like it.

 

[Jorgen Grahn]

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