Organizing Code - Packages

[xkenneth]

All,

I apologize if this is a commonly asked question, but I didn't
find anything that answered my question while searching.

So what I have right now is a few packages that contain some commonly
used functions and another package that contains all of my custom
error classes. I want these error classes available to me in all of
the other packages in my library. Currently to achieve this at the top
of every module file I have the line "from My.Library.Errors import
*", my problem with this is that it manages to import the Errors into
every scope that they are used. I'm still pretty new to Python, and my
approachs are probably very rooted in C/C++ (I've had the hardest time
getting over not being able to overload functions), but am I doing
this correctly?

Also, are there any good tutorials/examples out there of how to
organize your python code into packges?

Thanks for all the help!

Regards,
Ken

[Bruno Desthuilliers]

xkenneth a écrit :

All,

I apologize if this is a commonly asked question, but I didn't
find anything that answered my question while searching.

So what I have right now is a few packages that contain some commonly
used functions and another package that contains all of my custom
error classes. I want these error classes available to me in all of
the other packages in my library. Currently to achieve this at the top
of every module file I have the line "from My.Library.Errors import
*", my problem with this is that it manages to import the Errors into
every scope that they are used.

Ain't that what you want ??? Having "these error classes available to me
in all of the other packages in my library" ?

If you're worried about perfs or whatever, don't worry, a module is only
imported once - next imports will only bind the names in the importing
namespace.

I'm still pretty new to Python, and my
approachs are probably very rooted in C/C++ (I've had the hardest time
getting over not being able to overload functions), but am I doing
this correctly?

Yes, that's the right thing to do.

Also, are there any good tutorials/examples out there of how to
organize your python code into packges?

Most of the Python-specific aspects should be covered by the tutorial
(the one in the doc). Else, it's as usual, trying to have high cohesion
and low coupling.

Ah, yes, a couple of things:
- avoid the 'one-class-per-file' syndrom. It's perfectly ok to have tens
of classes in a same module
- plain functions are ok too - no need to stick everything in classes.

HTH

[xkenneth]

Ah, yes, a couple of things:
- avoid the 'one-class-per-file' syndrom. It's perfectly ok to have tens

Yes but i find it hard to edit classes easily when I have more than
one class per file.

Regards,
Ken

[Paul Rudin]

xkenneth <xk******@gmail.comwrites:

>Ah, yes, a couple of things:
- avoid the 'one-class-per-file' syndrom. It's perfectly ok to have tens

Yes but i find it hard to edit classes easily when I have more than
one class per file.

Why?

[Wildemar Wildenburger]

Paul Rudin wrote:

xkenneth <xk******@gmail.comwrites:

>>Ah, yes, a couple of things:
- avoid the 'one-class-per-file' syndrom. It's perfectly ok to have tens

Yes but i find it hard to edit classes easily when I have more than
one class per file.

Why?

Scroll-Blindness would be a good reason.

It would however be completely rediculous to create a file for every
10-liner class you have (and I have found that Python classes tend to be
rather short).

/W

[xkenneth]

On Sep 7, 2:04 pm, Wildemar Wildenburger
<[e-mail]:

Paul Rudin wrote:

xkenneth <[e-mail]:

>Ah, yes, a couple of things:
- avoid the 'one-class-per-file' syndrom. It's perfectly ok to have tens
Yes but i find it hard to edit classes easily when I have more than
one class per file.

Why?

Scroll-Blindness would be a good reason.

It would however be completely rediculous to create a file for every
10-liner class you have (and I have found that Python classes tend to be
rather short).

/

Yes I agree, "Scroll-Blindness" it just gets long and confusing.
Navigating isn't so bad (emacs) here. I have another question for
something I don't quite understand.

How do import statements that are declared at the top of a python
module work?

for instance....

from MyModule.Objects import *

class Class:
def function:
#here i cannot access the things that should have been
imported from the above statement
#i printed the dir() function to verify this

This happens when I'm using the Class i just defined from another
python script. I can understand if that statement at the top if not
being executed when I import the above defined class, if so, I need to
access the classes from the other modules, so where do I put the
import statement? Is it proper to put import statements inside of
class function definitions? This solves my problem but seems VERY
incorrect coming from my old C/C++ ways.

Thanks Again!

Regards,
Ken

[Marc 'BlackJack' Rintsch]

On Sat, 08 Sep 2007 12:42:19 -0700, xkenneth wrote:

How do import statements that are declared at the top of a python
module work?

They import the module. ;-)

for instance....

from MyModule.Objects import *

class Class:
def function:
#here i cannot access the things that should have been
imported from the above statement
#i printed the dir() function to verify this

Sorry I don't believe this. This doesn't even compile because the method
`function()` lacks the arguments in the definition. Please post actual
code and actual tracebacks you get.

And `MyModule` is a bad name for a package.

Ciao,
Marc 'BlackJack' Rintsch

[David]

>

How do import statements that are declared at the top of a python
module work?

for instance....

from MyModule.Objects import *

class Class:
def function:
#here i cannot access the things that should have been
imported from the above statement
#i printed the dir() function to verify this

I have seen this myself (stuff seemingly not imported) when 2 modules
import each other, perhaps indirectly, and try to use elements from
each other (at the global/declaration step, rather than in functions.
Logic that runs later (not during the import phase) still works fine,
however)). This sounds like the problem you're having, but your code
snippet isn't complete enough for me to tell. The way to fix this is
generally to move out stuff used by both modules into a separate
module.

Another reason can be that the imported module should be but isn't
setting the "__all__" variable. (in general the "import *" syntax is
frowned upon, it reduces readability).

[David]

How do import statements that are declared at the top of a python

module work?

http://docs.python.org/tut/node8.html

[xkenneth]

On Sep 8, 3:35 pm, David <[e-mail]:

How do import statements that are declared at the top of a python
module work?

http://docs.python.org/tut/node8.html

On Sat, 08 Sep 2007 12:42:19 -0700, xkenneth wrote:

How do import statements that are declared at the top of a python
module work?

They import the module. ;-)

for instance....
from MyModule.Objects import *

class Class:
def function:
#here i cannot access the things that should have been
imported from the above statement
#i printed the dir() function to verify this

Sorry I don't believe this. This doesn't even compile because the
method
`function()` lacks the arguments in the definition. Please post
actual
code and actual tracebacks you get.
And `MyModule` is a bad name for a package.

Ciao,
Marc 'BlackJack' Rintsch

Code doesn't compile in python. This is pseudo code anyways.
Can't post actual code and tracebacks because the code is proprietary.
"MyModule" is pseudo code, and i forgot the arguments, the actual code
and errors are unimportant for this question.

[Tommy Grav]

On Sep 8, 2007, at 8:04 PM, xkenneth wrote:

>
Code doesn't compile in python. This is pseudo code anyways.
Can't post actual code and tracebacks because the code is proprietary.
"MyModule" is pseudo code, and i forgot the arguments, the actual code
and errors are unimportant for this question.

The code and traceback is important because the behavior you claim
is not easily explained without more information. How are we suppose
to help
you make your code run, when you can't even properly explain the
problem?

Cheers
Tommy

[Bruno Desthuilliers]

xkenneth a écrit :

>>Ah, yes, a couple of things:
- avoid the 'one-class-per-file' syndrom. It's perfectly ok to have tens

Yes but i find it hard to edit classes easily when I have more than
one class per file.

Why so ? Could it be that your classes are growing too fat ?

[Bruno Desthuilliers]

xkenneth a écrit :

On Sep 7, 2:04 pm, Wildemar Wildenburger
<[e-mail]:

>>Paul Rudin wrote:

>>>xkenneth <[e-mail]:

>>>>>Ah, yes, a couple of things:
>- avoid the 'one-class-per-file' syndrom. It's perfectly ok to have tens

Yes but i find it hard to edit classes easily when I have more than
one class per file.

>>>Why?

Scroll-Blindness would be a good reason.

It would however be completely rediculous to create a file for every
10-liner class you have (and I have found that Python classes tend to be
rather short).

/

Yes I agree, "Scroll-Blindness" it just gets long and confusing.
Navigating isn't so bad (emacs) here.

Don't you use ECB ? (Emacs Code Browser) ?

But even without it, it's a problem of file size, not a problem of
number of classes.

(snip question about import, cf other answers)