Project organization and import

[Jorge Godoy]

"Martin Unsal" <martinunsal at gmail.com> writes:

> On Mar 6, 9:19 am, "Chris Mellon" <arka... at gmail.com> wrote:
>> You do? Or do you only have trouble because you don't like using "from
>> foo import Foo" because you need to do more work to reload such an
>> import?
>
> More work, like rewriting __import__ and reload??? :)
>
> There's a point where you should blame the language, not the
> programmer. Are you saying I'm lazy just because I don't want to mess
> with __import__?

I *never* messed with __import__.  And one of my systems has more than 15
packages, with an average of 7 more subpackages plus __init__.py...

Why do you need messing with __import__?

> I was clearly talking about files and you assumed I was talking about
> namespace. That's Pythonic thinking... and I don't mean that in a good
> way!

Hmmm...  Why not?  How are you going to track down where is something, on
which file?  I can make sucessive imports and I can subclass things, so I
might be importing a subclass of a subclass of the class that provides the
method that I want to change.  Having a direct correlation helps me a lot with
big projects.  For small ones I don't care since they are very simple and a
grep usually takes me directly to where I want (just to avoid tools that map
classes to files that are specific to one IDE or editor). 

> Because I have written a project with 50,000 lines of Python and I'm trying
> to organize it in such a way that it'll scale up cleanly by another order of
> magnitude. Because I've worked on projects with millions of lines of code
> and I know about how such things are organized. It's funny, I'm a newbie to
> Python but it seems like I'm one of the only people here thinking about it
> as a large scale development language rather than a scripting language.

I don't se a problem scaling my biggest project with, now, 65K lines of code.
What are the problems you're seeing for yours?  In fact, the Python part of
this code is the easiest to deal with.  And there's ctypes involved here,
which messes things up a bit since I need to keep C + Python in sync.

And if I once imagined I'd write that many LOC and would reach the millions of
LOC of *Python* code then it would certainly make me feel comfortable knowing
that this approach *do* scale.  At least to me and to the ones that work with
me and use the system...  Implementing new features is fast and extremely
modular.  There are modules specific to one client, modules specific to
another, modules shared between all clients, etc.  It isn't a monolithic take
all or nothing.  And even like that it works.

There are customizations on some features that only exists at one client's
branch, there are customizations that might be selected "on the fly" by
choosing something on a preferences screen, etc.

It is a "normal" (but rather complex) application on any aspect that we see
around.  And it scales.  I don't fear changing code.  I don't fear adding new
features.  It "simply works".


-- 
Jorge Godoy      <jgodoy at gmail.com>