:
Re: Package organization
From:
Matt Good <[EMAIL PROTECTED]>
Date:
Sat, 15 Jul 2006 15:57:22 -0700
To:
python-list@python.org
One class per module? Sounds like you've been programming in Java
Mike Wyatt wrote:
> I've been playing around with Python for a few months now, and I just
> recently started looking at packages to organize my growing project. So
> far, I've been organizing my application into one class per module.
> This has been working pretty well. For example, I simply
Mike Wyatt wrote:
> I've been playing around with Python for a few months now, and I just
> recently started looking at packages to organize my growing project. So
> far, I've been organizing my application into one class per module.
> This has been working pretty well. For example, I simply "imp
I've been playing around with Python for a few months now, and I just
recently started looking at packages to organize my growing project. So
far, I've been organizing my application into one class per module.
This has been working pretty well. For example, I simply "import
timer", then use
Kent Johnson wrote:
> Paul Boddie wrote:
> > Yes, Python does this - it puts the directory of bar.py (B in this
> > case) in sys.path, but not the directory in which you're sitting when
> > you run the program from the shell (A in this case).
>
> This seems to be OS dependent. If I put 'print sys.
fortepianissimo wrote:
> Paul Boddie wrote:
> > fortepianissimo wrote:
> > > Hm this doesn't work. Say I have the following directory structure:
> > >
> > > A
> > > |--- util
> > > ||--- foo.py
> > > |
> > > |--- B
> > > |--- bar.py
> > >
> > >
> > > And bar.py has this line
> > >
> > > fr
Paul Boddie wrote:
> Yes, Python does this - it puts the directory of bar.py (B in this
> case) in sys.path, but not the directory in which you're sitting when
> you run the program from the shell (A in this case).
This seems to be OS dependent. If I put 'print sys.path' at the start of
site.py (
Paul Boddie wrote:
> fortepianissimo wrote:
> > Hm this doesn't work. Say I have the following directory structure:
> >
> > A
> > |--- util
> > ||--- foo.py
> > |
> > |--- B
> > |--- bar.py
> >
> >
> > And bar.py has this line
> >
> > from util import foo
>
> This would only work with A in
Interesting - Python seems to act differently under Windows then. Here
I'm using Python 2.4 on Mac OS X. With all of the files, directories
and command exactly like yours, it's still not working.
One thing I noticed is that you have this 'C:\\WUTemp\\A' when you
print sys.path in B/bar.py, but min
fortepianissimo wrote:
> Hm this doesn't work. Say I have the following directory structure:
>
> A
> |--- util
> ||--- foo.py
> |
> |--- B
> |--- bar.py
>
>
> And bar.py has this line
>
> from util import foo
This would only work with A in sys.path/PYTHONPATH. However...
> I then run
>
>
fortepianissimo wrote:
> Hm this doesn't work. Say I have the following directory structure:
> A
> |--- util
> ||--- foo.py
> |
> |--- B
> |--- bar.py
>
> And bar.py has this line
>
> from util import foo
>
> I then run
>
> python B/bar.py
>
> in directory A. Still got er
Hm this doesn't work. Say I have the following directory structure:
A
|--- util
||--- foo.py
|
|--- B
|--- bar.py
And bar.py has this line
from util import foo
I then run
python B/bar.py
in directory A. Still got error
ImportError: No module named util
A check of sys.path in bar
Kent Johnson <[EMAIL PROTECTED]> writes:
> What I do is run always from the base directory (violates your first
> requirement). I make a util package to hold commonly used code. Then B and D
> both use
> from util import foo
>
> In Python 2.5 you will be able to say (in D, for example)
> from
fortepianissimo wrote:
> Say I have the following package organization in a system I'm
> developing:
>
> A
> |B
> |C
> |D
>
> I have a module, say 'foo', that both package D and B require. What is
> the best practice in terms of
Ok I guess a little more "hunch" might be needed to elicit suggestions.
If I chose to put foo in A, is there a way for code in B to import foo
from A? Namely, is there a way to import stuff from a parent
directory/package?
If it's not possible without changing sys.path, what's the path of
least ef
Say I have the following package organization in a system I'm
developing:
A
|B
|C
|D
I have a module, say 'foo', that both package D and B require. What is
the best practice in terms of creating a 'common' package that hosts
'foo'? I want
In <[EMAIL PROTECTED]>, Thomas
Lotze wrote:
> Assume I have a package called PDF. Should the classes then be called
> simply File and Objects, as it is clear what they do as they are
> imported from PDF? Or should they be called PDFFile and PDFObjects, as
> the names would be too undescrip
On Wednesday 22 June 2005 01:42 pm, Thomas Lotze wrote:
> Assume I have a package called PDF. Should the classes then be called
> simply File and Objects, as it is clear what they do as they are
> imported from PDF? Or should they be called PDFFile and PDFObjects, as
> the names would be to
F. Petitjean wrote:
> As you whish :-)
Damn freedom of choice *g
> if in the package ie in the __init__.py (not the best idea) from PDF
> import File as PDFFile # always possible
Technically, this is clear - however I don't like the idea of giving the
same thing different names, especially if
Le Wed, 22 Jun 2005 20:42:24 +0200, Thomas Lotze a écrit :
> Hi,
>
> I've two questions concerning organizing and naming things when writing
> a Python package.
>
> Assume I have a package called PDF. Should the classes then be called
> simply File and Objects, as it is clear what they do as th
Hi,
I've two questions concerning organizing and naming things when writing
a Python package.
- Naming of classes: I'm writing a library that reads PDF files. I have
a data structure that represents the large-scale structure of a PDF
file (header, trailer, incremental updates etc), and I'll h
21 matches
Mail list logo
