Project organization and import

Martin Unsal martinunsal at gmail.com
Tue Mar 6 17:24:04 CET 2007


Bruno Desthuilliers wrote:
> <imho>
> Which is not a problem. reload() is of very limited use for any
> non-trivial stuff.
> </imho>

Now that I've heard this from 5 different people it might be sinking
in. :) :) I really do appreciate all of you taking the time to explain
this to me.

When I started using Python a few years ago I was very excited about
the fact that it was an interpreted language and offered a more
interactive workflow than the old compile-link-test workflow. As my
project has grown to be pretty sizeable by Python standards, I tried
to continue taking advantage of the tight, reload-based, interpreted-
language workflow and it's become really cumbersome, which is
disappointing. However y'all are right, giving up on reload() doesn't
mean Python is inadequate for large projects, just that it doesn't
live up entirely to what I perceived as its initial promise. Once I
adjust my mindset and workflow for a life without reload(), I'll
probably be better off.

I'd like to point out something though. More than one of the people
who responded have implied that I am bringing my prior-language
mindset to Python, even suggesting that my brain isn't built for
Python. ;) In fact I think it's the other way around. I am struggling
to take full advantage of the fact that Python is an interpreted
language, to use Python in the most "Pythonic" way. You guys are
telling me that's broken and I should go back to a workflow that is
identical in spirit, and not necessarily any faster than I would use
with a compiled language. While that might be the right answer in
practice, I don't feel like it's a particularly "good" answer, and it
confirms my initial impression that Python package management is
broken.

I think you should be asking yourselves, "Did we all abandon reload()
because it is actually an inferior workflow, or just because it's
totally broken in Python?"

I have one question left but I'll ask that in a separate post.

Martin




More information about the Python-list mailing list