[Twisted-Python] twisted.web split
Hello, all. I talked a bit with glyph and radix about splitting twisted.web. It's over 1500 lines now, and I think it's becoming unmanageable. Here is how I propose it will be split:
- twisted/web/html.py -- HTML generation helpers - twisted/web/protocol.py -- Web protocols (HTTP and Gloop, currently) - twisted/web/resource.py -- Resources.
Specifically:
- twisted/web/resource.py
class Data(Resource): class Interface(Resource): class FileTransfer: class DirectoryListing(Interface): class File(Resource): class CGIDirectory(Resource): class ErrorPage(Interface): class NoResource(ErrorPage): class ResourceIssue: class ResourceSubscription(Resource): class PythonScript(Resource): class CGIScript(Resource): class FilteredScript(CGIScript): class PHPScript(FilteredScript): class MethodDirectory(Interface): class UserDirectory(Interface):
- twisted/web/html.py
def escape(text): def PRE(text): def output(func, *args, **kw): def date_time_string(msSinceEpoch=None): def d(**z):
- twisted/web/protocol.py
class HTTP: (might move completely outside) class Request(http.HTTPRequestHandler): class CGIProcess(net.Process): class ResourcePublish(gloop.Handler): class ResourcePublisher(gloop.Server, authenticator.SessionManager): class HTTPHandler(net.GenericHandler): class Server(net.GenericServer, authenticator.SessionManager, config.Configurable): class HTTPClient(net.GenericClient, log.Logger): class HTTPCallback(HTTPClient): class ResourcePublisherClient(gloop.Client, log.Logger):
From a simple grep I think I've covered everything.
Anything else that might have slipped should be easy to put somewhere.
One addition: twisted/web/library.py - same as twisted/webutils.py.
On Mon, Apr 30, 2001 at 08:14:46PM +0300, Moshe Zadka wrote:
Hello, all. I talked a bit with glyph and radix about splitting twisted.web. It's over 1500 lines now, and I think it's becoming unmanageable. Here is how I propose it will be split:
- twisted/web/html.py -- HTML generation helpers
- twisted/web/protocol.py -- Web protocols (HTTP and Gloop, currently)
- twisted/web/resource.py -- Resources.
How about splitting it into more files than that? It's a bit easier generally to navigate and isolate problems, reuse for other things, and update things. Maybe a file for CGI/epy code, a file for getting files and such, a file for generating automatic directory listings, etc.
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?)
- Thyrr@bb3.betterbox.net
On Mon, 30 Apr 2001, Moshe Zadka wrote:
Hello, all. I talked a bit with glyph and radix about splitting twisted.web. It's over 1500 lines now, and I think it's becoming unmanageable. Here is how I propose it will be split:
- twisted/web/html.py -- HTML generation helpers
- twisted/web/protocol.py -- Web protocols (HTTP and Gloop, currently)
- twisted/web/resource.py -- Resources.
Specifically:
twisted/web/resource.py
class Data(Resource): class Interface(Resource): class FileTransfer: class DirectoryListing(Interface): class File(Resource): class CGIDirectory(Resource): class ErrorPage(Interface): class NoResource(ErrorPage): class ResourceIssue: class ResourceSubscription(Resource): class PythonScript(Resource): class CGIScript(Resource): class FilteredScript(CGIScript): class PHPScript(FilteredScript): class MethodDirectory(Interface): class UserDirectory(Interface):
twisted/web/html.py
def escape(text): def PRE(text): def output(func, *args, **kw): def date_time_string(msSinceEpoch=None): def d(**z):
twisted/web/protocol.py
class HTTP: (might move completely outside) class Request(http.HTTPRequestHandler): class CGIProcess(net.Process): class ResourcePublish(gloop.Handler): class ResourcePublisher(gloop.Server, authenticator.SessionManager): class HTTPHandler(net.GenericHandler): class Server(net.GenericServer, authenticator.SessionManager, config.Configurable): class HTTPClient(net.GenericClient, log.Logger): class HTTPCallback(HTTPClient): class ResourcePublisherClient(gloop.Client, log.Logger):
From a simple grep I think I've covered everything.
Anything else that might have slipped should be easy to put somewhere.
-- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.%7Bpython,debian,gnu%7D.org
Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
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).
participants (4)
-
Chris Armstrong -
Glyph Lefkowitz -
Moshe Zadka -
Thyrr