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

Groups > comp.lang.python > #81492 > unrolled thread

Re: Embedded python 'scripting engine' inside Python app

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Embedded python 'scripting engine' inside Python app Patrick Stinson <patrickkidd@gmail.com> - 2014-11-24 22:38 -0900

#81492 — Re: Embedded python 'scripting engine' inside Python app

> On Nov 23, 2014, at 4:57 AM, Chris Angelico <rosuav@gmail.com> wrote:
> 
> 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)

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

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web