Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #20028 > unrolled thread

Naming convention for in-house modules (Newbie question)

Back to article view | Back to comp.lang.python

Contents

  Naming convention for in-house modules (Newbie question) HoneyMonster <someone@someplace.invalid> - 2012-02-08 17:15 +0000
    Re: Naming convention for in-house modules (Newbie question) Chris Rebert <clp2@rebertia.com> - 2012-02-08 09:49 -0800
    Re: Naming convention for in-house modules (Newbie question) Laurent Claessens <moky.math@gmail.com> - 2012-02-09 15:00 +0100
      Re: Naming convention for in-house modules (Newbie question) Arnaud Delobelle <arnodel@gmail.com> - 2012-02-09 14:36 +0000
        Re: Naming convention for in-house modules (Newbie question) Laurent Claessens <moky.math@gmail.com> - 2012-02-09 18:42 +0100
        Apparent "double imports" (was: Naming convention for in-house modules (Newbie question)) HoneyMonster <someone@someplace.invalid> - 2012-02-09 18:53 +0000
          Re: Apparent "double imports" (was: Naming convention for in-house modules (Newbie question)) Ian Kelly <ian.g.kelly@gmail.com> - 2012-02-09 12:02 -0700
            Re: Apparent "double imports" (was: Naming convention for in-house modules (Newbie question)) HoneyMonster <someone@someplace.invalid> - 2012-02-09 19:40 +0000
              Re: Apparent "double imports" Dave Angel <d@davea.name> - 2012-02-09 15:05 -0500
                Re: Apparent "double imports" HoneyMonster <someone@someplace.invalid> - 2012-02-09 21:57 +0000

#20028 — Naming convention for in-house modules (Newbie question)

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.

[toc] | [next] | [standalone]

#20030

On Wed, Feb 8, 2012 at 9:15 AM, HoneyMonster <someone@someplace.invalid> wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#20076

> 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

[toc] | [prev] | [next] | [standalone]

#20079

On 9 February 2012 14:00, Laurent Claessens <moky.math@gmail.com> wrote:
>
>> 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/

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

-- 
Arnaud

[toc] | [prev] | [next] | [standalone]

#20090

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

Well... I've to sleep. Sorry :(

Laurent

[toc] | [prev] | [next] | [standalone]

#20095 — Apparent "double imports" (was: Naming convention for in-house modules (Newbie question))

On Thu, 09 Feb 2012 14:36:52 +0000, Arnaud Delobelle wrote:

> On 9 February 2012 14:00, Laurent Claessens <moky.math@gmail.com> wrote:
>>
>>> 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/
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#20096 — Re: Apparent "double imports" (was: Naming convention for in-house modules (Newbie question))

On Thu, Feb 9, 2012 at 11:53 AM, HoneyMonster <someone@someplace.invalid> wrote:
> 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.

[toc] | [prev] | [next] | [standalone]

#20101 — Re: Apparent "double imports" (was: Naming convention for in-house modules (Newbie question))

On Thu, 09 Feb 2012 12:02:03 -0700, Ian Kelly wrote:

> On Thu, Feb 9, 2012 at 11:53 AM, HoneyMonster
> <someone@someplace.invalid> wrote:
>> 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.

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

[toc] | [prev] | [next] | [standalone]

#20102 — Re: Apparent "double imports"

On 02/09/2012 02:40 PM, HoneyMonster wrote:
> On Thu, 09 Feb 2012 12:02:03 -0700, Ian Kelly wrote:
>
>> On Thu, Feb 9, 2012 at 11:53 AM, HoneyMonster
>> <someone@someplace.invalid>  wrote:
>>> 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.
> 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.

-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#20115 — Re: Apparent "double imports"

On Thu, 09 Feb 2012 15:05:52 -0500, Dave Angel wrote:

> On 02/09/2012 02:40 PM, HoneyMonster wrote:
>> On Thu, 09 Feb 2012 12:02:03 -0700, Ian Kelly wrote:
>>
>>> On Thu, Feb 9, 2012 at 11:53 AM, HoneyMonster
>>> <someone@someplace.invalid>  wrote:
>>>> 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.
>> 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.

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web