Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #81365

Re: Embedded python 'scripting engine' inside Python app

Show key headers only | View raw

On Mon, Nov 24, 2014 at 12:20 AM, Patrick Stinson <patrickkidd@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)

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

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: Embedded python 'scripting engine' inside Python app Chris Angelico <rosuav@gmail.com> - 2014-11-24 00:57 +1100

csiph-web