Rabid Ramblings ][

Python "Web Framework Shootout" paper online

Since PyCon papers are perhaps best distributed in a DIY fashion, I've
made my paper available at:

  The Web Framework Shootout
  http://colorstudy.com/docs/shootout.html

This paper compares several web application development frameworks
(CherryPy, SkunkWeb, Webware, Zope, Spyce, Albatross, jonpy, Twisted),
with much of the commentary in the form of commented code examples.  I
hope it will help inform the Python community on some of the choices
available in web development.

-- Ian Bicking ianb@colorstudy.com http://colorstudy.com
4869 N. Talman Ave., Chicago, IL 60625 / 773-275-7241 
"There is no flag large enough to cover the shame of
 killing innocent people" -- Howard Zinn 

SuperVillain: He Has More Friends Now

Look out for mongoose!

Phil also reported on a package his company plans to release next week, called "mongoose".

The role of Mongoose is to provide a framework for to cleanly catch and report otherwise uncaught exceptions in distributed python applications.

Mongoose will provide a much less intimidating error message than a stack trace (or, under wxPython, an app that suddenly vanishes). Bundled reporting styles include summary and detailed log files, email, and wxPython alerts. They looked very clean in the demo.

Perhaps the most interesting part of the package is that Mongoose creates an ID for each exception, similar to the Talkback ID from Mozilla builds. This ID is a short (5 digit?) hash of the method signatures in the stack trace. This means the ID should be unique to the call stack at time of exception. (By not using file or line numbers in the hash, the IDs should remain constant across product versions.)

The short ID can be easily communicated over the phone to tech support, or be used as a lookup key for user self support. (After the problem is found and a work around created the first time...)

While, in an ideal world, there would be no uncaught exceptions, Mongoose promises to ease support issues for early releases and products which rely on 3rd party libraries.

PyChecker usage

Phil Lindsay gave a good talk about PyChecker at this month's Bay Piggies meeting.

From his work on a large project, he offered some tips on usage:

• keep PyChecker rules in a separate file, also under source control. Don't clutter the source with PyChecker directives.
• To keep track of "temporary" messages that are okay, don't create an exception for it. Rather, check in the output of PyChecker alongside the source, and diff against the prior PyChecker output. That way, any changes to the temporary issues will show up.

Phil reports that most Python projects now use PyChecker. It has become more difficult for the PyChecker team to find "un checked" code to use for testing. That's a good thing...

Transition Strategies: Windows to Linux

CVS2RSS

The Social Meaning of RDF

Kendall Grant Clark has an interesting piece on whether or not "social meaning" should be explicitly a part of RDF semantics.

Deep stuff, but having recently Googled myself and found one of the primary references to be a saterical piece I forwarded (with attribution) to a list that was archived, I can see the desire to express a social context to information....

PyDS Installation on Win32 Platforms

WebAIM 2003 Online Web Accessibility Training Event

Backup and restore instructions

Extracted from the comments to the 0.4.14 announcement (which can't be linked directly):

Hal asked:

Re the cloud -- actually, what I'm missing are the items that go with a first time push (I assume) - the gifs for the XML and email icons, etc.

Should there be some sort of "site refresh" function, since all the file exist on my local desktop?

Or a "site pull" if i wanted to start using PyDS from a different box?

Are these just new tools I can write and dump into the right column? geschrieben von Hal Wine um 03:13:44 am 03.03.2003

Georg answers:

To upstream stuff that should have gone in the first time, just touch those files (make there date current). Then upstreaming will push them up next time.

Pull isn't there, and since XMLStorageSystem doesn't have a directory reading functionality, wouldn't be possible to implement. There was one, once, but it's obsoleted.

To start PyDS from a different box, just backup your local copy, upstream the backup and do a restore from the other machine. To backup currently you only can use the timer in the preferences (add a backup timer to the list) and enable the backup upstreaming in your preferences.

To restore use the pyds-restore script.

Ahh, slash fixed....

So, the fix to the slashes was a trivial

  files = map( lambda x: re.sub( r'\\', '/', x ), files )

In an ideal world, that probably should be protected to only be done when the local system's directory separator is not slash. I think that would be done as:

  dirSep = os.path.join( 'a', 'b' )[1:-1]

  if dirSep != '/':

    files = map( lambda x: re.sub( dirSep, '/', x ), files )

Oops! Buggy patch

OOPS!!! my patch seemed to work, but it caused the event log to become corrupted. Reverting to Georg's patches, and removing the patch file below.

Running PyDS under Windows

Georg's patch worked fine. I crafted a slightly different one, which allows the log files to be written, by patching Daemonize.py (and tweaking install_handlers in Server.py)

My patch -- tested only on Windows 98 -- may be found at http://dtor.com/PyDS/Bug_01_fix.tgz

Bug on Windows 98

Ran into a bug -- not sure exactly what's up.

Apparently, the working directory is off when saveMultipleFiles is executed, as none of the local files can be found (see below for event log messages).

Georg found and fixed the bug! Awesome

Old bug details are at dtor.com/PyDS/Bug_01.html

PyDS on Win 98

It wouldn't fly under Cygwin, but that's probably because I grabbed the Mk4py.dll from the MetaKit site, rather than compiling all myself.