JJinuxLand

"""This is a convenient way to deeply nest try/finally statements.""" __docformat__ = "restructuredtext" # Created: Tue Oct 11 08:42:23 PDT 2005 # Author: Shannon -jj Behrens # Email: jjinux@users.sourceforge.net # # Copyright (c) Shannon -jj Behrens. All rights reserved. from traceback import print_exc def tryFinally(tasks, handleFinallyException=None): """This is a convenient way to deeply nest try/finally statements. It is appropriate for complicated resource initialization and destruction. For instance, if you have a list of 50 things that need to get intialized and later destructed via using try/finally (especially if you need to create the list dynamically) this function is appropriate. Given:: tasks = [ ((f_enter_0, enter_0_args, enter_0_kargs), (f_exit_0, exit_0_args, exit_0_kargs)), ((f_enter_1, enter_1_args, enter_1_kargs), (f_exi

Concerning MochiKit : It's well written. I like the Pythonic feel. I like the docs, the humor, and the heavy regression testing. I even like the code, which is a huge compliment! Concerning DojoToolkit : I like the fact that it's a community of people who have each given up their own framework to work together. I like the mailing list. I like the event system and the package system (although I haven't used it yet). I don't like the fact that it doesn't feel quite as polished by a perfectionist as MochiKit. I also hate the part of the style guide that says you should not use a space before "{" in: if (foo){ } I don't know of any other style guide that suggests this. Does this mean I'm going to pick one over the other? Nope. Both have good parts. Fortunately, they're compatible. It looks like I'm going to have to use them both. Ideally, the guys from MochiKit would take a bunch of their stuff and shove it into DojoToolkit. Th

Have you ever noticed that some of your best work happens in the bathroom? The other day I was trying to resolve a particularly sticky user interface problem. I thought I'd try out some AJAX, Asynchronous JavaScript and XML. It wasn't really working out, and although they really aren't the same thing, I tried some CLOROX, Common Language Object Reference Over XML. Displeased with that, I fell back to COMET, Common Object Method External Transport. Next I thought I'd try some old fashioned BLEACH, Binary Language Exports And C Headers; however I made sure to remove all the COMET first because I've heard that mixing COMET and BLEACH can have disastrous side effects. I think I was most satisfied with CLOROX, especially thanks to its BLEACH heritage. I found that all of these options were better than SOAP, Simple Object Access Protocol, which leaves a sticky substance behind that is nearly impossible to get rid of.