
- Image via CrunchBase
def set_trace(): import pdb, sys sys.stdout = sys.__stdout__ sys.stdin = sys.__stdin__ debugger = pdb.Pdb() debugger.set_trace(sys._getframe().f_back)


def set_trace(): import pdb, sys sys.stdout = sys.__stdout__ sys.stdin = sys.__stdin__ debugger = pdb.Pdb() debugger.set_trace(sys._getframe().f_back)


My first problem with it is that pdb simply doesn’t work. Why not? Because GAE hijacks your stdout and prints in on the web page. This by itself should ring bells, seriously cgi wrapper? *checks calendar* What do you mean it’s 2009? Are you sure you didn’t mean 1999? But apparently i’m not the only one to have that problem, people have come up with the solution, explicitly pass the file descriptors to pdb. It usually boils down to something like:
def set_trace(): import pdb, sys debugger = pdb.Pdb(stdin=sys.__stdin__, stdout=sys.__stdout__) debugger.set_trace(sys._getframe().f_back)
Great, now i have a debugger that works. Until it doesn’t. For example trying to debug any POST statements has turned fruitless for me:
> /home/redduck666/dev/abj/st/trunk/views/auth.py(91)post() -> login = self.request.get('login') (Pdb) print self.request (Pdb) print 'wtf??'
This is using the above defined set_trace, as you can see it doesn’t print anything to the stdout and instead prints it to web page when ‘c’ in pdb is hit. Why? Who knows?
Than there is the datastore initialization problem i’ve already been rambling about. You can’t out of the box write to GAE datastore from python script. You’d think an engineer driver web company would get this right, such as do the initialization in the model classes not some magical part of dev_appserver.py. But fear not it get’s better! For example my frontend developer is complaining that sometimes she can login with the username, sometime she can not! The best part is that i have a script executed before the dev_appserver.py to create some dummy data, it wasn’t working. Than i cleaned my datastore dir and surprise surprise, the exact same script executed in the exact same way works now. If that ain’t magic i don’t know what is.
What happens if something goes wrong with the appcfg.py update? Who knows?
Checking if new version is ready to serve. Closing update: new version is ready to start serving. 2009-08-16 05:23:29,819 ERROR appcfg.py:1272 An unexpected error occurred. Aborting. Traceback (most recent call last): File "/root/abj/GAE/1.2.3/google/appengine/tools/appcfg.py", line 1265, in DoUpload self.Commit() File "/root/abj/GAE/1.2.3/google/appengine/tools/appcfg.py", line 1141, in Commit self.StartServing() File "/root/abj/GAE/1.2.3/google/appengine/tools/appcfg.py", line 1194, in StartServing app_id=self.app_id, version=self.version) File "/root/abj/GAE/1.2.3/google/appengine/tools/appengine_rpc.py", line 344, in Send f = self.opener.open(req) File "/usr/lib/python2.5/urllib2.py", line 387, in open response = meth(req, response) File "/usr/lib/python2.5/urllib2.py", line 498, in http_response 'http', request, response, code, msg, hdrs) File "/usr/lib/python2.5/urllib2.py", line 425, in error return self._call_chain(*args) File "/usr/lib/python2.5/urllib2.py", line 360, in _call_chain result = func(*args) File "/usr/lib/python2.5/urllib2.py", line 506, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) HTTPError: HTTP Error 500: Internal Server Error Rolling back the update. Error 500: --- begin server output --- Server Error (500) A server error has occurred. --- end server output ---
