Nick Gammon said:
Quote:
for i in range( 50 ):
note( "It's now ", now(), " since epoch" )
time.sleep( 2 )
Assuming this does what it looks like, I wouldn't do it.
It works fine in Python. time.sleep() does 'hang' - but only current thread, not the whole interpreter. Try it on Python interactive prompt or - alternatively - just believe me ;)
Nick Gammon said: is to use Lua coroutines.
Argh! To ... with Lua! (Meaning - I know basics of this language, but I just don't want to use it if I don't have to.) Coroutines are very easy to implement in Python, there are even few external libraries ready to use, but if you want lightweight coroutines you can just use Python native generators. In Lua docs there is comparision of coroutines with generators - but it's very outdated and I'm sure that nowadays there is no single thing you can achieve with coroutines that you can not with generators.
But that's not the point - various techniques, like coroutines or deferreds in Twisted are nice, of course, but are NOT threads. You can not use ANY blocking operation in coroutines, while you can do this in separate thread. Let's say I want to read some data from open socket - socket.recv( 1024 ) will block, if there is no data to read, stopping all scripting. Of course, you can use non-blocking socket and check if there is some data, reading it only when necessary - but using separate thread is simpler.
Nick Gammon said:
There is no real possibility for a "Python bug", only a bug that affects all script engines. However scripting has been active for quite a while now (like, years) and no-one else complains.
It's very easy to explain - only Ruby offers threads similar to Python's and my guess is that they don't work either, but scripting with Ruby is even less popular (I think) than with Python. I'm not sure about PERL (googled - it has threading, done with starting new interpreter for each thread. If I was a betting person I'd say it doesn't work either), but JS and friends are (I think?) single threaded by nature. Quick googling:
Quote: PHP has no built in support for threading.
Quote: There's no true threading in JavaScript.
and so on.
Nick Gammon said:
However, if the Python DLL has some "memory" itself,
It probably has - import statements are cached and this cache seems to be cleared only when MUSHClient is restarted.
Quote:
Again, all script languages other than Lua are done the same way.
Well, I can live with that, no big deal. With my reloading routine and occasional restarts while developing it's just a bit uncomfortable. The 'world' object is accessible only in one file, but hey - I wrote simple wrapper module, which - if initialised - is importable everywhere and is friendlier than original, printing meaning of return code if not equal to 0 automatically.
[I can't resist:
class Wrapper( object ):
def __init__( self, w ):
self.world = w
def __getattr__( self, name ):
if not hasattr( self.world, name ):
raise Exception( "No such method or attribute!" )
attr = getattr( self.world, name )
if not callable( attr ):
return attr
func = attr
def wrap( *args, **kwargs ):
ret = func( *args, **kwargs )
if ret is None:
ret = 0
try:
msg = smart_ret[ int( ret ) ]
except:
return ret
if ret != 0:
self.world.note( name )
self.world.note( msg )
return msg
return wrap
com = None
def init( world ):
global com
com = Wrapper( world )
beautiful, isn't it? ]
Working around weird paths which made imports impossible was easy, like with mod_wsgi and apache, so I did it very quickly. "script" attribute of triggers, that needs to be in main script file and has to be directly callable (object.method as a trigger won't work)? No problem, I wrote simple dispatcher and TriggerRegistry class which maps triggers to any callable. world.Note accepting only strings? It's even easier, just wrap it with some printer object. And so on...
Now I have seven script files, still long way to go - and for few weeks I haven't play my MUD. But hey, programming is better than playing, right? ;)
Also, I see you're no python fan and I don't want to convince you to become one right now. I just want to tell you that - while for ordinary users it's just fine - scripting support is quite restrictive for programmers (which hearing words "global variable" scream in horror, for example), and I guess any Ruby or even Perl developer scripting for MC would agree with me. I understand that it's WSH fault (I have to read more about it, I know almost nothing now), but I know for sure, that there are better ways for embedding scripting languages.
[Wow, I missed one thing - MUSHClient source is now open! Sorry, last time I checked (few years ago...) it wasn't.] |