Project structure - Best practices
Filip Gruszczyński
larger than a single module and I would like to do it right. I google
it a bit, finding some stuff about not using src directory (which I
have seen so many times, that I believed it be standard) and using
packages. Still, there are few things, that I would like to achieve
with this structure:
* being able to use pychecker a lot - catching all typos in one shot
instead of running app many times really saves me a lot of time
* being able to write some unit tests
* having clean division of code among packages and modules (I have
seen some projects, where modules are pretty large - I would like to
keep them logically divided, event if they stay smaller)
My project is a tool for people interested in role playing games. My
current structure looks something like this:
/src
rpgDirectory.py (main script, running the app)
src/rpg
plans.py
support.py
gui.py
iosystem.py
src/rpg/character
model.py
sheet.py
gui.py
handlers.py
requirements.py
The problem is, that modules from src/rpg/character use classes
defined in support.py. Therefore I have to use absolute paths to
import it and this works only, when I run rpgDirectory.py. When I use
pychecker, it can't import this module and fails. Any suggestions, how
can I avoid this and what structure should I use?
--
Filip Gruszczyński
Jean-Paul Calderone
Filip Gruszczyński
That's exactly what I have read before posting here ;-)
--
Filip Gruszczyński
Aaron Watters
I too would like to see a meatier discussion of best practices
for python packagizing. I particularly object to jcalderone's
suggestion that all tests should be within the package. Often my
test cases are 100 times the size of the code, if you include
sample data -- it doesn't make sense to install it, I think.
Lately I tend to have something like
root/
setup.py
README.txt
packagename/
main source modules
submodules...
test/
test code and submodules
doc/
scripts/
testdata/
demos/
etcetera... I have no real idea if this is a good
way to do it, but it works for me in isolation.
I'm completely confused about any implications related to
integrated system testing or "easyinstall"...
Wise, pragmatic advice would be appreciated. (But if we
could avoid the "buzzillion directories" approach prevalent
in the java alternative universe, that would be nice.)
-- Aaron Watters
===
Now we see the violence inherent in the system!
Help! Help! I'm being repressed!
Martin P. Hellwig
> On Nov 30, 11:55 am, "Filip Gruszczyński" <grusz...@gmail.com> wrote:
>>> http://jcalderone.livejournal.com/39794.html
>> That's exactly what I have read before posting here ;-)
>>
>> --
>> Filip Gruszczyński
>
> I too would like to see a meatier discussion of best practices
> for python packagizing. I particularly object to jcalderone's
> suggestion that all tests should be within the package. Often my
> test cases are 100 times the size of the code, if you include
> sample data -- it doesn't make sense to install it, I think.
I agree on that. But I like to add a couple of my thoughts :-)
In my opinion the structuring of your project depends very much on what
the project is itself. If it is a more a library sort of thing then I
tend to keep it as small and simple as possible, with the main objective
to be simple to understand when interfacing with it. I usually structure
the package like how I think somebody else would expect it to be.
When I am doing an application type of code for myself, I usually end up
organizing my program the way it is the easiest to maintain, if
necessary in this case I would sacrifice small and simple over
robustness and maintainability.
When I am starting a project which is either a payed contract job or I
anticipate other participants, I orientate my project more around
documentation and management, I have written an article in the past
about that (generally written it was still more aimed to the client I
was working at that moment). If anybody is interested you can get it
here:
http://dcuktec.googlecode.com/svn/trunk/documentation/best_practises/DITDD/deliverables/DITDD.pdf
ymmv
Rafe
Hi,
I have read in many places that relative imports aren't recommend as a
standard. This includes PEP 8 (http://www.python.org/dev/peps/
pep-0008/) which states:
" - Relative imports for intra-package imports are highly discouraged.
Always use the absolute package path for all imports.
Even now that PEP 328 [7] is fully implemented in Python 2.5,
its style of explicit relative imports is actively discouraged;
absolute imports are more portable and usually more readable."
...and I completely agree. I always use the standard import form
unless absolutely necessary. However, I use 'as' to shorten the path
to the last module. For example:
>>> import app.foo.bar as bar
>>> instance = bar.Class()
The only "relative" import I use when I am getting another module in
the same package. If I have:
app/
__init__.py
constants.py
foo/
__init__.py
bar.py
here.py
utils/
__init__.py
... and I am inside app/foo/here.py, I might have some imports at the
top of the module which look like this...
import app.constants as appC
import app.utils
import bar
Python will look for 'bar' in the local package before looking through
the python path. I could have imported constants as just "c", but
single letter variables are dangerous and I work with an application
where it is common in the community to use 'c' for
'constants' (regardless of the danger). Lastly, I could import
'app.utils' as 'utils', but this is such a common module name that I
like to preserve the name-space or at least prefix it (so I suppose
something like 'apputils' would be acceptable, but I'd only be saving
one character, the '.', so what's the point?).
I find that no matter how well I plan what my structure will be, I end
up making small changes such as flattening a sub-package or converting
a module to a sub-package to break things down further. As someone who
recently started learning python, I would recommend that you just make
a quick sketch of what you think might work and then just begin
coding. Adjust to logic along the way.
At some point planning begins to eat time rather than save it. get
through the fastest initial 80%, maybe push for a few more %, then
just go for it (I assume you have this luxury. If not then you
probably have a team that can help refine the plan anyway.)
Hope this helps.
- Rafe
Aahz
Rafe <rafe...@gmail.com> wrote:
>
>...and I completely agree. I always use the standard import form
>unless absolutely necessary. However, I use 'as' to shorten the path
>to the last module. For example:
>>>> import app.foo.bar as bar
>>>> instance = bar.Class()
Why bother with ``as`` in this case?
from app.foo import bar
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"It is easier to optimize correct code than to correct optimized code."
--Bill Harlan