| |
| |
| |
|
Page: 1 2 3
Comments:
<0> :-)
<1> i can't do exec textfile because i want it to have persistence
<1> so if it's called the next time, its variables would all be there
<1> also, do you have any idea on how i could call a function?
<1> right now i just tack a "\n\nFUNCTIONNAME(\"\"\"ARGUMENT\"\"\")" to the end of the string
<1> but if the argument has a """ in it it would break
<0> exec is just a way of executing Python code when all you have is a string containing it
<1> well, yes
<0> in practice you can just call it yourself with FUNCTIONNAME("ARGUMENT")
<0> so I'm not sure where you're going
<1> i'm making a game client
<1> which would be programmable
<0> if you use exec and don't specify locals or globals arguments, the results will be persistent
<1> i'm specifying globals because of the callbacks
<1> oh hmm
<1> locals are shared between exec calls?
<1> let me clarify
<0> if you want the effect of what are essentially plugins, then you're better off using a module approach rather than executing chunks of code
<0> no, locals aren't shared
<0> (I mean, they'd be the locals from whatever block you executed exec from)
<1> i want scripts to 1) be persistent 2) use callbacks 3) be executed in their own space
<0> yes then you want modules, not exec/execfile
<1> i can't follow a modular approach because i want it to be compatible with another program, so i can't design an API
<1> pretty much all i have to work with is the string with the code
<0> I mean Python modules, not "modular" in a general sense
<1> yes, i understand
<1> that's not an option though :(
<0> if you want the code to be persistent, then just keep a separate globals/locals dictionary for each chunk of code you're executing
<1> yes, i am right now
<0> when you use:: exec string, {}, {}
<1> the only problem so far is the function call
<0> you're making a new dictionary each time and so there's no persistent
<0> persistence
<1> i'm saving the dictionaries
<0> what function call?
<1> the file contains functions i can call to get their functionality
<1> so i append the "\n\nFUNCTIONNAME(\"\"\"ARGUMENT\"\"\")" thing to the string
<1> depending on the function i want to call
<0> why not just do:: exec codeString, g; g.FUNCTIONAME("ARGUMENT")
<0> where g is your persistent dictionary
<1> oh, i can do that?
<1> interesting
<1> that's great, actually
<0> if codeString is a string representing Python code that defines a FUNCTIONNAME, yeah
<0> it's all the same stuff, there's nothing special about exec
<1> yes, it should work
<1> i'll go try it, thanks a lot :)
<0> it makes Python just the same as what you're typing in yourself :-)
<0> sure
<1> i hadn't realized the functions were in the globals dict :p
<0> well if you specified a locals dictionary it might be in there instead
<0> depends on the details of what's in your code string
<1> it's just a bunch of function definitions
<1> well, that's all my program needs to see, anyway
<0> if it's only defining stuff, then don't even bother p***ing in a locals dictionary
<0> just use globals
<0> then exec s, g; g.function(...
<0> )
<1> yes, that's what i'll do, thanks a lot :)
<0> sure
<1> hmm
<1> oh right
<1> it's g["functionname"](arguments)
<1> that's great
<0> err, right, sorry
<1> you just saved me a huge headache :)
<1> so hmm, i just need to call exec() once and store the globals, then?
<0> if all the code strings do is define functions, yeah
<1> great great
<1> i don't even need the script string, fantastic
<0> now if they do a lot of interaction within themselves then that might get tricky, you might have to move toward modules (but you already said you couldn't)
<1> well, the only interaction is, my program calls a function, the function provides callbacks
<1> it doesn't even return a value
<0> but it has to interact with something, right?
<0> is it something you p*** in when you call it
<1> yes, the functions have 2-3 arguments
<1> that's all it needs
<0> k
<0> should be fine then
<1> it's basically text matching
<1> yes, i think so
<1> i'm making an eggdrop-style bot
<2> what are the dependencies to non-python code?
<1> what, of my bot?
<2> writing a bot in Python would make it very simple to extend it by using Python itself...
<0> yeah, I have a pure Python bot I'll replacing quincunx with eventually
<2> just curious. You said you couldn't use e.g. modules because of some non-Python code
<1> i'm designing plugins to be compatible with another program, so I can't use the python way of imports etc
<1> ah
<1> well, it's a MUD bot
<1> and i want it to be compatible with MUSHclient, another client
<1> which uses XML to store its plugins
<1> if anyone actually uses it and it grows, I don't think extending it will be a problem
<2> it probably involves a scripting language implementation?
<1> but right now i just want it to run the scripts i've already done
<1> no, MUSHclient uses python, among others
<2> it = the original
<1> through windows' COM scripting i think
<1> my bot will only support python, but all my scripts are written in python anyway, so no problem there
<1> xihr: supybot is a nice IRC bot if you want one
<1> written in python
<0> already got one that's working, just need to teach it to manage ops
<0> (on a private IRC network)
<1> you made one?
<1> ah
<0> it's also multiprotocol
<0> y
<1> interesting
<1> what did you use for sockets?
<0> asyncore/asynchat
<0> (it can hook into other features)
<0> for instance it also uses irclib
<1> is it better than twisted?
<0> asyncore/asynchat?
<1> oh hmm, i never knew it was a standard library
<0> well it's simpler
<1> err, i didn't know
<0> it's not quite as advanced, but at the same time it's not quite as attitude-ridden
<1> hmm, that's interesting
<1> i only need a connection anyway, and i could do with one less library to depend on
<1> by the way, how can i unroll a tuple (to p*** the elements as arguments to a function)?
<0> if you have to do your own basic I/O, or write your own protocol, Twisted really doesn't gain you anything unless you already know it fluently
<0> aFunction(*aTuple)
<1> is that the call or the declaration?
<1> damn, i didn't know that either
<0> it's both, actually
<0> def f(x, y, *args): ...
<0> and t = (1, 2, 3); g(*t) # where g takes 3 arguments
<1> ah, i knew that one, yes
<1> i see, that's very nice
<1> about asyncore, what do you mean basic i/o?
<1> you mean the comm protocol?
<1> or even lower?
<0> the protocol, asyncore manages sockets
<0> asynchat is what you want if they're mainly text-based
<0> asyncore/asynchat are part of something called Medusa, you can poke around for it
<1> ah, well, it's a MUD, so the protocol is just telnet
<0> Medusa isn't part of the library but asyncore/asynchat (the key elements) are
<1> i see
<0> truth is for simple I/O like that even handling the sockets yourself is pretty straightforward
<1> yeah, that's all i need in twisted too
<1> although I'm thinking of listening on a socket for incoming connections, and i'll need authentication for that
<1> so twisted's cred module looks nice
<1> though i don't think it'll be horribly complex to write, either
<0> unless you already know it, or it fits very well with your approaches, or it already has features fleshed out enough that you need, then it may not be right for you
<1> indeed
<1> i'm glad i made my code modular, now i can just plug the other module in
<1> do you know if there is any asynchronous timer library?
<0> there's signal.alarm or some such
<0> probably not what you want
<1> hmm, i want my client to be able to have timers that send data after an amount of time
Return to
#python
or
Go to some related
logs:
quakenet shmups
icy torer
FATAL: Error inserting snd_emu10k1 (/lib/modules/2.6.15-gentoo-r1
#politics
efnet torm
bollygrounds username and password
#politics
#politics
#nhl
nick cartwe
|
|