Naming convention for in-house modules (Newbie question)

[HoneyMonster]

I am quite new to Python (2.7 on Linux), and have built a few modules
using wxPython/wxGlade for GUI elements and Psycopg2 for database access.
I adhere mostly to the PEP8 guidelines, and use Pylint to help with
quality control.

So far I have been *very* impressed. Due to Python's straightforwardness
and the wealth of documentation, results have been excellent.

Here is my question: I would like to start an in-house library of small
modules to import, for things like error handling/logging. That's easy
enough, but is there a recommended way of naming such modules? I am
concerned about avoiding name clashes with standard modules and site
packages.

Thanks.

 

[Chris Rebert]

I am quite new to Python (2.7 on Linux), and have built a few modules
using wxPython/wxGlade for GUI elements and Psycopg2 for database access.
I adhere mostly to the PEP8 guidelines, and use Pylint to help with
quality control.

So far I have been *very* impressed. Due to Python's straightforwardness
and the wealth of documentation, results have been excellent.

Here is my question: I would like to start an in-house library of small
modules to import, for things like error handling/logging. That's easy
enough, but is there a recommended way of naming such modules? I am
concerned about avoiding name clashes with standard modules and site
packages.

You could put all the modules under a single package; then you only
need to worry about avoiding 1 name conflict.

Cheers,
Chris

 

[Laurent Claessens]

Here is my question: I would like to start an in-house library of small
modules to import, for things like error handling/logging. That's easy
enough, but is there a recommended way of naming such modules? I am
concerned about avoiding name clashes with standard modules and site
packages.

Thanks.

This is not 100% an answer to the question, but you should read that :
http://www.python.org/dev/peps/pep-0008/

This explain you WhatCaseToChoose for_naming youVariables.

Laurent

 

[Arnaud Delobelle]

This is not 100% an answer to the question, but you should read that :
http://www.python.org/dev/peps/pep-0008/

The OP mentions PEP 8 in the bit of his message that you *don't* quote.

 

[Laurent Claessens]

The OP mentions PEP 8 in the bit of his message that you *don't* quote.

Well... I've to sleep. Sorry

Laurent

 

[HoneyMonster]

The OP mentions PEP 8 in the bit of his message that you *don't* quote.

Thank you for that Arnaud, and thanks to Chris R. I'm going along with
Chris's suggestion for the moment.

One issue I have run into, which may or may not be a problem: I am
finding that modules in the in-house "library" package sometimes have to
import modules like sys and os, which are also imported by the "calling"
module. Is this a problem or an overhead, or does it just result in two
names for the same object?

Thanks again.

 

[Ian Kelly]

One issue I have run into, which may or may not be a problem: I am
finding that modules in the in-house "library" package sometimes have to
import modules like sys and os, which are also imported by the "calling"
module. Is this a problem or an overhead, or does it just result in two
names for the same object?

Two names for the same object. When a module is imported, the module
object is stored in the sys.modules dict. Further imports of the same
module just return the same module object from sys.modules.

 

[HoneyMonster]

Two names for the same object. When a module is imported, the module
object is stored in the sys.modules dict. Further imports of the same
module just return the same module object from sys.modules.

Excellent! It seems it is not a problem at all, then. Thank you.

 

[Dave Angel]

Excellent! It seems it is not a problem at all, then. Thank you.

Just to add a little subtlety, there is a problem with mutually
recursive imports. If module aaa imports module bbb, and modole bbb
imports aaa, there can be some problems. Most can be avoided by putting
the imports right at the beginning of each file, so no work has been
done before doing the imports. Then by the time some code tries to use
them, they're all resolved. One exception is if you try to import the
file that is your script file. This one is made into a module by the
special name of __main__, and if you import it using the original name,
you'll have two copies around. That can lead to some very interesting
anomalies.

Better is to make sure no loops exist in the importing tree, which is a
desirable structuring goal anyway. When two modules need each other,
try to either move the common stuff to a 3rd module they each import, or
do something with callbacks or other mechanism that reflects what's
really going on.

Of cours that last paragraph is strictly my own opinion.

 

[HoneyMonster]

Just to add a little subtlety, there is a problem with mutually
recursive imports. If module aaa imports module bbb, and modole bbb
imports aaa, there can be some problems. Most can be avoided by putting
the imports right at the beginning of each file, so no work has been
done before doing the imports. Then by the time some code tries to use
them, they're all resolved. One exception is if you try to import the
file that is your script file. This one is made into a module by the
special name of __main__, and if you import it using the original name,
you'll have two copies around. That can lead to some very interesting
anomalies.

Better is to make sure no loops exist in the importing tree, which is a
desirable structuring goal anyway. When two modules need each other,
try to either move the common stuff to a 3rd module they each import, or
do something with callbacks or other mechanism that reflects what's
really going on.

Of cours that last paragraph is strictly my own opinion.

Thanks, Dave. I'm sure I won't have a problem with circular imports. The
structure I have in mind is:

A package (say ihlib) consisting of in-house "library" routines for local
use. The directory above ihlib will be added to PYTHONPATH, so that
imports can find ihlib.

"Top level" modules will import ihlib.blah as necessary in order to avoid
code duplication amongst them.