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