Considering using python for something, and need a bit of info :)

[Martijn Faassen]

PartyG2816 at aol.com wrote:
[snip description of muds]

For a mud done in Python, check out:

http://www.accessoft.com/moop/

Not that I ever used MOOP (I did use its predecessor, POO). I just used
that great index of all things Pythonic, the Vaults of Parnassus:

http://www.vex.net/parnassus

There's also a thread involving someone who wants to make a new
Python interpreter that compiles to MUQ bytecodes; apparently also a
mud system.

There's also PyGCS, a tiny one-room mud written in Python. I've used
this one and it does what it promises to do quite well (which isn't
too much, but it's fun, and it's probably interesting to disect it's
source to learn more about using networking with Python).

http://sourceforge.net/project/?form_grp=378

>     Could the Python interpreter be embedded and used in a way that would 
> allow me to use it like this within my application?

Sure, it can. There's I think one problem remaining, which I'll describe
later on.
 
>  I've downloaded the 
> interpreter and gone through parts of the tutorial... I love it. *chuckles* 

I had the same feeling.

> I'm a C++ programmer at heart,

Came from the same direction. I must admit I don't do too much C++ these
days. :)

> but I can definately see some advantages to 
> using Python for osme things.. I think it would be fairly easy to teach a 
> non-programmer how to use it within the context of my application would be 
> fairly easy with a person dedicated to helping the nephytes and a few docs.

You may end up coding most of your mud system in Python. I warned you. :)
(not that this is a bad idea, it's just that you're probably thinking about
coding it with C++ mostly still -- this could very well change).

>     Another concern of mine is: how secure can it be? IE can i restrict 
> certain aspects of it based upon a condition? Say I have a a normal builder, 
> ie someone who simply makes areas and may perform a few scripts for them, I 
> wouldn't want to let him do certain things... Whereas me as head programmer, 
> I would have access to many more options within my scripts :) Or take a 
> normal "player".  I'm going to be allowing small scripts and macros and such 
> for my players to automate a few 'boring' things, I would want to give them 
> access to a limited set of use, and not let them say re-arrange everything in 
> the room. *chuckles*

There's the rexec and Bastion modules that may help here, but I think you
need to implement most of the security system itself. This can definitely
be done; I imagine MOOP has one, and I'm sure Zope does:

http://www.zope.org

Zope isn't a mud, but it's in Python and does allow people to execute
limited Python expressions in a secure environment. You may want to look
at their security model. Also interesting in this respect is PythonMethods,
a Zope extension that allows people to use Python securely over the
web. I can't explain what Zope does briefly, but be assured people have
looked into this.
 
>     Ah well, maybe you peoples understand what I'm asking and can help, I'd 
> appreciate any response :) If you have questions about something I may need 
> to clarify, then by all means ask and I'll try my hardest. ;)

Okay, the trickiest part which I'm not sure any of the things I listed
solves is the 'infinite loop' problem; what if your ordinary user does:

while 1:
   pass

Does the entire mud hang now? How to manage this?

The classical way an lpmud (for instance) does it is by allocating a limited
number of 'ticks' to each execution thread; if the thread takes too many
ticks then it's automatically aborted. Using ticks also helps in 
simulating multithreading. Default Python however does not support such
ticks, but possibilities you may wish to look at are:

Stackless Python
http://www.pns.cc/stackless/stackless.htm

I'm excited about this development even though it makes my brain explode
so far. Someone more familiar with it could chime in on if this really
would solve the 'infinite loop' problem.

There's also Python Microthreads, which implement an efficient way to
do lots of tiny threads in Python. Again I'm not sure if this will help
for muds, but it's neat anyway. Last I heard was that its functionality
will be folded into Stackless Python. Look here:

http://world.std.com/~wware/uthread.html

The Zope way to avoid this problem is simply to restrict the kind of code
you can write, I think, and to add extra checks to loops. I'm not sure
how far this is along, though.

> p.s. - If it turns out that yall think Python could be suitable for osmething 
> like this,

Python would definitely be great for this! I've been managing an lpmud
for years and I've been vaguely toying with the idea of adding Python
to the driver (and then slowly displace the legacy lpc code :). Not that
I'll ever get time to do this. I've had at least one lpmud guru agree
with me, after he took a look at Python. 

> could you include a few linkst o places that discuss and give some 
> working examples of embedding python in another application and running 
> scripts through it using whatever API is inherent in Python for that use? :)

You may want to check out the Vaults, and there's the Extending and 
Embedding documentation on www.python.org. Also you may want to check out
Swig, at www.swig.org, though that's more to extend Python with
your own C or C++ modules than the other way around.

PS, I love the Vaults. I can sound like Tim Peters without actually
having to know anything. :)
 
Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?