[Twisted-Python] twisted.web split
glyph at twistedmatrix.com
Tue May 1 03:12:46 EDT 2001
On Tuesday 01 May 2001 00:29, you wrote:
> How about splitting it into more files than that?
> 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
> 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)
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
More information about the Twisted-Python