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

grackle <davidhuebel@gmail.com> writes:

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

-- 
 \        "A hundred times every day I remind myself that [...] I must |
  `\       exert myself in order to give in the same measure as I have |
_o__)                received and am still receiving" —Albert Einstein |
Ben Finney

On Jan 14, 4:47 pm, Ben Finney <bignose+hates-s...@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.  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

grackle <davidhuebel@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

On Jan 14, 11:44 am, grackle <davidhue...@gmail.com> wrote:
> 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

On Jan 14, 6:28 pm, Ben Finney <bignose+hates-s...@benfinney.id.au>
wrote:
> grackle <davidhue...@gmail.com> 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
> <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

grackle <davidhuebel@gmail.com> writes:

> On Jan 14, 6:28 pm, Ben Finney <bignose+hates-s...@benfinney.id.au>
> wrote:
> > 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 :-)

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.

-- 
 \        "I spent a lot of money on wine and women, and like a fool I |
  `\                              squandered the rest."  -- Benny Hill |
_o__)                                                                  |
Ben Finney

> 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

-- 
Posted via a free Usenet account from http://www.teranews.com

"Tobiah" <toby@tobiah.org> wrote in message 
news:478d113a$0$26041$88260bb3@free.teranews.com...
|
| > 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. 

On Mon, 14 Jan 2008 15:58:49 -0800 (PST), grackle <davidhuebel@gmail.com> wrote:
> On Jan 14, 4:47 pm, Ben Finney <bignose+hates-s...@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!