snorble wrote:
> My question is, why do the modules bar and foo show up in mypack's
> dir()? I intend for Foo (the class foo.Foo) and Bar (the class
> bar.Bar) to be there, but was not sure about the modules foo and bar.
> $ ls mypack/*.py
> bar.py
> foo.py
> __init__.py
>
> $ cat mypack/__init_
My question is, why do the modules bar and foo show up in mypack's
dir()? I intend for Foo (the class foo.Foo) and Bar (the class
bar.Bar) to be there, but was not sure about the modules foo and bar.
My big picture intention is to create smaller modules, but more of
them (like I am used to doing w
On Mar 26, 12:33 pm, Scott Sharkey <[EMAIL PROTECTED]>
wrote:
> Here's the directory structure that I've got so far:
>
> project top level directory
>setup.py
>company eventually, we'll have other modules
> __init__.py
> error.py
Hello all,
I've read a number of the python books, and several online tutorials
about modules and packaging, but not one addresses this issue, so I
thought I'd ask here...
I am building a library for use in an internal project. This library
is the client side interface to a REST-ful service th
Sorry about not being clear. I have been downloading quite a few
packages for examples, but have not found a good example of man page
building from optparse.
seismic-py
- setup.py
- seismic
- __init.py__
- bulk of the code *.py
- scripts
- programs that go in bin/
Hi All,
I am rearranging the layout of one of my python projects so that it
more closely conforms to how most python projects seem to work. I now
have a structure like this:
seismic-py
- setup.py
- seismic
- bulk of the code
- scripts
- programs that go in bin
I am usi
