> On Nov 23, 2014, at 4:57 AM, Chris Angelico <ros...@gmail.com> wrote: > > On Mon, Nov 24, 2014 at 12:20 AM, Patrick Stinson <patrickk...@gmail.com> > wrote: >> I think this is the way I’ll take it, and for all the same reasons. The only >> way they can break it is if they really want to. I guess anything other >> Franken-apps would be interesting to hear about too. And I’ll still stick it >> on the app store. >> > > (Please note, the convention on this list/newsgroup - as with most > tech lists - is to put your text underneath what you're quoting - > so-called "bottom-posting" or "interleaved" style.) > > Yep. I got in some trouble for doing this at my last salaried > employment, because the boss couldn't get his head around the idea > that an XKCD 936-compliant password is secure enough for a code > executor, and that the absence of a code executor makes debugging much > harder. (In the end, I just renamed it to "calculator" so it wasn't so > obvious, and left it there. Debugging is important.) In my open-source > MUD client, Gypsum, there's a code executor built-in, which I use > regularly as a simple calculator, and also to manipulate the program's > internals. Some examples: > >> /x 123+456*789 > 359907 >> /x asin(.5)*180/3.14159 > 30.0000253399374 >> /x "Test "*5 + "Haha" > "Test Test Test Test Test Haha" >> /x window.mainwindow.iconify() > GTK2.Window > (and the main window has just been minimized, aka iconified)
Thanks for the stories in this and the other thread. I love these interesting problems that push the limits :) > > Basically, any expression that I type after "/x" will be parsed and > executed as code. There's no sandboxing at all; it's executed in its > own globals() and locals(), but if it wants to tinker with external > state, it's free to do that. Since all the code is there for the user > to peruse anyway, I don't distinguish between "this you may do" and > "this you may not do", but instead between "this is pledged to be > supported throughout this major version" and "this is undocumented, > use at your own risk" - on the understanding that most of the latter > category is actually pretty stable, and can happily be used anyway. > > Interpreted languages tend to make this kind of thing fairly easy, and > on the day you have a weird error that you can't figure out, you will > be no end of glad you have this. No triggering a core dump and then > doing a post-mortem, just examine state live, using the language's > natural syntax. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
