Project organization and import

[Bruno Desthuilliers]

Martin Unsal a écrit :
> On Mar 5, 9:15 am, "Chris Mellon" <arka... at gmail.com> wrote:
(snip)
> There are myriad other benefits of breaking up large files into
> functional units. Integration history, refactoring, reuse, as I
> mentioned. Better clarity of design. Easier communication and
> coordination within a team. What's the down side? What's the advantage
> of big files with many functional units?

What is a "big file" ?

(snip)
> However when I talk about what I think is "wrong" with the Pythonic
> way, obviously that's just my opinion formed by my own experience.

Your own experience *with Python* ? or any close-enough language ? Or 
your experience with C++ ?

(snip)
> Python still takes time to load & "precompile".

compile. To byte-code, FWIW. Not "load & precompile". And - apart from 
the top-level script - only modified modules get recompiled.

> That time is becoming
> significant for me even in a modest sized project;

On what hardware are you working ??? I have my interpreter up and 
running in a couple milliseconds, and my box is a poor athlon xp1200/256.

> I imagine it would
> be pretty awful in a multimillion line project.

I still wait to see a multimillion line project in Python !-)

If you find yourself in this situation, then you there's certainly 
something totally wrong in the way you (and/or your team) design and code.

But anyway - remember that only the modified modules get recompiled.

> No matter how fast it is, I'd rather reload one module than exit my
> interpreter and reload the entire world.

Did you actually *tried* it ?

> This is not a problem for Python as scripting language. This is a real
> problem for Python as world class application development language.

Sorry to have to say so, but this is total bullshit IMHO - which is 
based on working experience.

>>Nobody I know uses reload() for anything more than trivial "as
>>you work" testing in the interpreter. It's not reliable or recommended
>>for anything other than that.
> 
> 
> That too... although I think that's unfortunate. If reload() were
> reliable, would you use it?

I wouldn't. It easier to rerun a simple test script and keep the 
interpreter opened with full state - and you're sure you have the 
correct desired state then.

>>This is
>>still a much faster way than compiling any but the most trivial of
>>C/C++ modules.
>  
> I'm with you there! I love Python and I'd never go back to C/C++. That
> doesn't change my opinion that Python's import mechanism is an
> impediment to developing large projects in the language.

What about basing your opinion on facts ? What about going with the 
language instead of fighting against it ?

> 
>>If you don't like working with explicit namespaces, you've probably
>>chosen the wrong language.
> 
> 
> I never said that. I like foo.Bar(), I just don't like typing
> foo.Foo() and bar.Bar(), which is a waste of space;  syntax without
> semantics.

May I say that the problem here comes from your insistance on putting 
each class in a single module ?

> 
>>I propose that the technique most amenable to source code management
>>is for a single file (or RCS level module, if you have a locking RCS)
>>to have everything that it makes sense to edit or change for a
>>specific feature.
> 
> 
> Oh, I agree completely. I think we're using the exact same criterion.

I really doubt you do. What Chris is talking about is grouping together 
what usually needs to change together.

> A class is a self-contained feature with a well defined interface,

So is a function. Should we put any single function in a separate module 
then ?

> just what you'd want to put in it's own file. (Obviously there are
> trivial classes which don't implement features, and they don't need
> their own files.)
> 
> 
>>You're also placing far too much emphasis on reload. Focus yourself on
>>unit tests and environment scripts instead. These are more reliable
>>and easier to validate than reload() in a shell.
> 
> 
> I think this is the crux of my frustration. I think reload() is
> unreliable and hard to validate because Python's package management is
> broken.

I think the "crux of your frustation" comes from your a priori. Fighting 
against a language can only bring you into frustration. If the language 
don't fit your brain - which is perfectly legitimate - then use another 
one - but don't blame the language for it.