Organizing Code - Packages

X

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
 
B

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
 
B

Bruno Desthuilliers

xkenneth a écrit :
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 ?
 
B

Bruno Desthuilliers

xkenneth a écrit :
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)
 
X

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
 
W

Wildemar Wildenburger

Paul said:
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
 
X

xkenneth

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
 
M

Marc 'BlackJack' Rintsch

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
 
D

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

xkenneth


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

Tommy Grav

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
 
G

GuillaumeC

They import the module. ;-)

Well, not only... They also include the names in the namespace. Using
the "import * from" form will bind in each of your modules the name of
the errors. You should use import XXX and then use the qualified name
XXX.myfunction. Then, you avoid conflicts between names and binding
every name from your module. See the documentation for reload() also.
Also, are there any good tutorials/examples out there of how to
organize your python code into packges?

This is not new, nor specific to Python, but I think it is a good
reference:
http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf
see section: Principles of Package Architecture
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,058
Latest member
QQXCharlot

Latest Threads

Top