Project organization and import

[Jorge Godoy]

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

> On Mar 5, 11:06 am, "Chris Mellon" <arka... at gmail.com> wrote:
>> I never advocated big files with many functional units - just files
>> that are "just big enough".
>
> Then we're in total agreement. I'm not sure why you thought my
> opinions were the result of baggage from other languages when you
> don't seem to actually disagree with me.

I believe the reason was that you were advocating one class per file.  "big
enough" might be more classes.  Or fewer... :-)

> I agree that there is some subtlety there, and I appreciate your
> example. However the fact that Python's module system essentially
> forces you to use "from foo import *" and that reload is almost
> entirely imcompatible with "from foo import *", I would say that
> reload is essentially useless.

The don't force you to that...  There are many modules that do, but they are
generally glueing your Python code to some other language (usually C) written
code.  This is common for GUI development, for example.

In fact, it is rare to me -- mathematics, statistics, database, web
development, testing -- to use this construction.  There are no modules that
demand that.

And you can also write:

    from foo import Bar, Baz

or even

    from foo import Bar as B1, Baz as B2  # OUCH! ;-)

> Well "from foo import Foo" is just a special case of "from foo import
> *". :) It still breaks reload. It still means you're restarting your
> interpreter even to do the most trivial development cycle.

That's what you get when you're working with instances of Foo...  I believe
that for classmethods this would work right.  So, again, it depends on your
code, how it is structured (and how it can be structured), etc. 

> Here's an analogy. In C, you can do an incremental build and run your
> modified application without having to first reboot your computer. In
> Python, where reload() is essentially the incremental build process,
> and the interpreter is essentially a virtual machine, you guys are
> saying that my best option is to just "reboot" the virtual machine to
> make sure I have a "clean slate". It may be the path of least
> resistance, but to say that it is necessary or inevitable is 1960s
> mainframe thinking.

How can you reload C code that would affect already running code --
ie. existing data, pointers, etc. -- without reloading the full program?  Even
changing and reloading a dynamic library wouldn't do that to already existing
code, so you'd have to "reboot" your application as well.



-- 
Jorge Godoy      <jgodoy at gmail.com>