Re: [Tutor] Cross-Module Interaction
On 26 February 2011 11:10, Corey Richardson wrote: > On 02/26/2011 06:05 AM, Walter Prins wrote: > > I'd be tempted to say you should not be worrying about such performance > > issues at this stage. > > Indeed, but I can't have every piece of variable information being saved > to disk and then read back again every time a player leaves or enters a > room, that'd just be silly! > Sure. I still think however that at this stage it's a much of a muchness. Modern PC's and disk caching subsystems being what they are, you likely won't really notice it either way until you're quite far along with this project. ;) (I'm not suggesting you should be willfully stupid of course, and the mere fact that you write the above indicates you're not, so there's no problem!) > Playing MUD's for a bit it gets annoying on a medium-size server when > you have to wait more than 3 seconds just to get how much health you > have after attacking some baddie. I won't be trying to pull every > microsecond of efficiency out of this, but I would like it to be > sensible and now waste time dawdling. > Sure. It's of course an assumption that the delay you see is due to disk I/O... (it may well be, but then again there's lots of possible reasons for things being slow...) > > (And the full quote is "We should forget about *small* efficiencies, say > about 97% of the time: premature optimization is the root of all evil." > (emphasis added)) > I know what the full quote is, I continue to be of the opinion that the point it makes is relevant, it's not worth worrying too much about. Pick a strategy that works sufficiently, you can always refactor and improve when needed. Good luck, Walter ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Cross-Module Interaction
On 26 February 2011 11:06, Corey Richardson wrote: > I ran them like this: > python use1.py > python use2.py > python plib.py > > Each file got its own instance of the interpreter. > Yes, but not because instances are intrinsically linked to seperate python modules, which is what it sounds like you're saying. In the above case you *explicitly* started the 3 python instances seperately yourself from the command line, giving each instance a file to run, which is why you got 3 seperate instances. It's nothing to do with the fact that you have 3 files as such. (You'd have had 3 instances even if you ran the same file 3 times.) If you e.g. ran "use1.py" which then imported or ran use2.py and use3.py they'd all have used the same instance. Similarly, if you'd opened all 3 files in IDLE, and ran them with F5 in turn, they'd all have run in the *same* interpreter instance.Perhaps you do understand and you've expressed yourself poorly or I've just miinterpreted what you meant, I just wanted to make sure you don't think that seperate files (modules) will by some magic always have their own instances (which is not the case in general.) Walter ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Cross-Module Interaction
On 02/26/2011 06:05 AM, Walter Prins wrote: > I'd be tempted to say you should not be worrying about such performance > issues at this stage. Indeed, but I can't have every piece of variable information being saved to disk and then read back again every time a player leaves or enters a room, that'd just be silly! Playing MUD's for a bit it gets annoying on a medium-size server when you have to wait more than 3 seconds just to get how much health you have after attacking some baddie. I won't be trying to pull every microsecond of efficiency out of this, but I would like it to be sensible and now waste time dawdling. (And the full quote is "We should forget about *small* efficiencies, say about 97% of the time: premature optimization is the root of all evil." (emphasis added)) -- Corey Richardson ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Cross-Module Interaction
On 02/26/2011 06:02 AM, Walter Prins wrote: > On 26 February 2011 05:33, Corey Richardson wrote: > >> Aha, that explains why I didn't get any results. Each file got its own >> interpreter instance. >> > > Not wanting to nit pick, but no: It's not that each *file* does has its own > interpreter instance, it's that every python instance that you start does > not automatically persist anything that gets created while it lives. In > other words, you can import many modules (files) into any given interpreter > instance, but whether or not the stuff gets persisted anywhere is a seperate > matter. > > Walter > I ran them like this: python use1.py python use2.py python plib.py Each file got its own instance of the interpreter. -- Corey Richardson ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Cross-Module Interaction
On 26 February 2011 05:33, Corey Richardson wrote: > > I'm slightly concerned about performance when it comes to > reading/writing to disk a lot when doing things like that, since if this > thing ever needs to scale I want it to be able to do that. > I'd be tempted to say you should not be worrying about such performance issues at this stage. Remember what Knuth said, "... premature optimization is the root of all evil" Suffice it to say you can push rather large amounts of disk I/O with Python, and you can always come up with creative caching systems or whatever once you get that far along and it proves to be a problem. Walter ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Cross-Module Interaction
On 26 February 2011 05:33, Corey Richardson wrote: > Aha, that explains why I didn't get any results. Each file got its own > interpreter instance. > Not wanting to nit pick, but no: It's not that each *file* does has its own interpreter instance, it's that every python instance that you start does not automatically persist anything that gets created while it lives. In other words, you can import many modules (files) into any given interpreter instance, but whether or not the stuff gets persisted anywhere is a seperate matter. Walter ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Cross-Module Interaction
"Corey Richardson" wrote I'm slightly concerned about performance when it comes to reading/writing to disk a lot when doing things like that, since if this thing ever needs to scale I want it to be able to do that. There is always an overhead but it depends what you mean by "a lot". You might choose to only write on updates, only write when users leave the system, only write when the system closes down or write periodically (either a timed period or when certain resource levels get above/below critical levels) Lots of options. You need to choose a strategy that works for your situation. -- Alan Gauld Author of the Learn to Program web site http://www.alan-g.me.uk/ ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Cross-Module Interaction
On 02/26/2011 12:11 AM, Steven D'Aprano wrote: > [steve@sylar ~]$ python > Python 2.5 (r25:51908, Nov 6 2007, 16:54:01) > [GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. > >>> import lib > >>> import a > >>> lib.g > [] > >>> a.do_stuff() > >>> lib.g > [42] > > > Of course, when your application exists (or in this case, the > interactive session), the changes to lib.g will be lost because they > only exist in memory. If you want data to persist across application > runs, you need to arrange for the application to save the data to disk, > and then read it again when it starts up. Aha, that explains why I didn't get any results. Each file got its own interpreter instance. > > Python has many tools for working with persistent data: Windows-style > ini files (module config parser), XML, JSON, Mac-style plists, YAML > (third-party module only), and pickles, to name only a few. In any case everything would be called in one interpreter, which I didn't know worked because I didn't test it like you showed it, but to be safe I definitely need to persist that data every once in a while. I'm slightly concerned about performance when it comes to reading/writing to disk a lot when doing things like that, since if this thing ever needs to scale I want it to be able to do that. Thank you, Steven -- Corey Richardson ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Cross-Module Interaction
Corey Richardson wrote: My first thought was to have a module specifically for holding things like that, global objects that all the interacting modules need access to. I did a simple test with a lib module, and then a few modules that simply added things to a list called g in that lib module, but the changes did not persist (tested with another module that printed the contents of lib.g) Perhaps you should give a *simple* example, but what you describe should work. Let's start with a very simple library module: # lib.py g = [] Now let's import it and use it from another module: # a.py import lib def do_stuff(): lib.g.append(42) Save those two files as named, and then import them into the interactive interpreter: [steve@sylar ~]$ python Python 2.5 (r25:51908, Nov 6 2007, 16:54:01) [GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import lib >>> import a >>> lib.g [] >>> a.do_stuff() >>> lib.g [42] Of course, when your application exists (or in this case, the interactive session), the changes to lib.g will be lost because they only exist in memory. If you want data to persist across application runs, you need to arrange for the application to save the data to disk, and then read it again when it starts up. Python has many tools for working with persistent data: Windows-style ini files (module config parser), XML, JSON, Mac-style plists, YAML (third-party module only), and pickles, to name only a few. -- Steven ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
[Tutor] Cross-Module Interaction
Greetings, Tutors (Sorry for the poor subject name, couldn't think of anything better) I'm writing a MUD server as part of a school project. Yes this is homework, but I'm not taking a traditional programming class (going through the OCW for CS50 at Harvard and getting credit). I'm in the design phase and am testing out a few things. One thing I will definitely need is a global players_online collection which will act much like the name implies. My first thought was to have a module specifically for holding things like that, global objects that all the interacting modules need access to. I did a simple test with a lib module, and then a few modules that simply added things to a list called g in that lib module, but the changes did not persist (tested with another module that printed the contents of lib.g) I'm probably thinking about this from the wrong direction. Is there something about this approach that I'm missing, or is there a different way I should be using? (If you're curious about the telephone data-transfer I was working on, I ran into too much trouble with the various sound libraries that exist to wrap over Alsa or JACK, so I put it off for the future after I'm more comfortable with C/C++) -- Corey Richardson ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
