"Martin Unsal" <[EMAIL PROTECTED]> writes: > On Mar 6, 9:19 am, "Chris Mellon" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> -- http://mail.python.org/mailman/listinfo/python-list