[Twisted-Python] twisted.web split

Glyph Lefkowitz 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 
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) 

                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |
                     @ t w i s t e d m a t r i x  . c o m

More information about the Twisted-Python mailing list