Mike Meyer wrote: > [EMAIL PROTECTED] writes: [comments about Mike Meyer's try python, I think] > > I had no trouble with from math import * followed by print pi, but > > there was no >>> prompt after the result appeared .. is that part of > > the 'closures' thing mentioned earlier? > > Hmm. Are you looking at mine <URL: > http://www.mired.org/home/mwm/try_python/ >, or Devans <URL: > http://www.datamech.com/devan/trypython/trypython.py >? Mine doesn't > handle code (though he's provide pointers I plan on using to make it > do so). I think he said his has problems with closures.
I'm renaming mine to the Python Online REPL or Online Python REPL, whichever you prefer, to help differentiate from Mike's. >From the actual recipe: <http://www.onlamp.com/python/pythoncook2/solution.csp?day=2> (The url changes every day as they move it one day back) if co.co_freevars or co.co_cellvars: raise ValueError, "Sorry, cannot pickle code objects from closures" I think that the code constructor (types.CodeType) doesn't take co_freevars or co_cellvars as an arg, so I can't directly create a new code object from the attribute of the old one with co_freevars and co_cellvars. I might be able to set the attributes after,but I'll have to test it out to see. > > Then I followed you "type 'help'" suggestion, which had me in stitches > > (sorry, it's been a long day and the Knob Creek was kicking in) -- I > > got exactly the message you'd expect, about help not being recognized > > and maybe help() would work. That's what triggered the idea for > > trapping errors. > > Hmm. help seems to work fine in both of them. license() fails the same > way in both of them (it tries to read from stdin, so....), which means > that you can probalby make help fail on them both if you work at it. > Printing and most things not explicitly called by my code isn't done correctly (strings to lines to strings again!), so most any printing non-single statements or input will probably break it. -- http://mail.python.org/mailman/listinfo/python-list
