On Tuesday 01 May 2001 00:29, you wrote:
How about splitting it into more files than that?
Maybe...
It's a bit easier generally to navigate and isolate problems,
I disagree. It's easiest if there is one module that you have to look through that contains as much as possible, since any decent editor will allow you to browse the classes in that file. (Any *tolerable* editor will at least let you do a regular-expression search). Most modern computers can fit a 1.5k file into main memory, even in a visual editor, so size requirements are specious. Having a billion modules where classes _might_ live is considerably worse.
reuse for other things,
I don't like reuse, and I hope to actively discourage it (I'll explain this more thoroughly at another time. This is yet another essay in the works for me...). If you're talking about *use*, well then, all that you're discussing about "easier" means "from twisted.web.server import File" or "from twisted.web.static import File". I don't see any meaninful ease-of-use in the name distinction...
and update things.
Since I have done approximately 90% of the updates to this project at this point, I just think I'll say "no" to that one ;)
Maybe a file for CGI/epy code, a file for getting files and such, a file for generating automatic directory listings, etc.
Segregating things along meaningful module boundaries is a useful division though, because it provides a meaningful way to expand that functionality, so I'll think about this. The categories you describe might actually be good (web.dynamic(CGI/epy)/web.static(Files/Directory Listings) frex).
Just my suggestion (though I've only looked at Twisted Python for a few days now, so maybe that's not a good way to do it?)
Not a bad comment though, especially the last part. Thanks. Although I tend to be quite argumentative on this topic (baaaaad experiences with python packages on my last project at work), I'd really like to see active discussion of how to break apart burgeoning modules into packages; it's an unpleasant problem as I've seen it so far, but with some consistently applied strategy I'm sure it could be a good thing. Given that code-harvesting seems to be my predominant "engineering" philosophy, I have a feeling that this sort of refactoring will be highly common on this project, especially in the near future (as each "core" module (web, reality, net) expands). -- ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://twistedmatrix.com/users/glyph