On 4 October 2012 04:11, Littlefield, Tyler <ty...@tysdomain.com> wrote: > pHello all: > I've seen frameworks like django reload files when it detects that they've > been changed; how hard would it be to make my engine reload files that it > detects were changed?
I tend to think that it's better to reload things explicitly. But if you do want to monitor your files for changes you can use something like this: http://packages.python.org/watchdog/ > I'm also curious how hard it would be to build in some > error recovery. For example right now when an exception occurs, the player > is sometimes just left hanging. The general idea is to try and make state changes atomic. In other words if an error occurs during an operation the previous state should be kept or restored. A simple way to do this is to ensure that anything that might generate an error is run before anything that changes state e.g.: def change_my_values(self, intvalue_string, floatvalue_string): # Do all processing first (might generate errors) iv = int(intvalue_string) fv = float(floatvalue_string) # Then change state self.intvalue = iv self.floatvalue = fv In this simple case, you can get the same effect with: def change_my_values(self, invalue_string, floatvalue_string): self.intvalue, self.floatvalue = in(intvalue_string), float(floatvalue_string) A more sophisticated way might use something like: oldstate = current_state() try: set_state(compute_new_state()) except: restore_state(oldstate) raise Naturally this is quite tedious if you have to put try/except everywhere, but this kind of exception handling can easily be factored out into a context manager. > It's a lot harder with Python for me, > because I don't get the compile-time errors that I would with c++ for > example to know that I did something wrong; while that's not always > useful/and by far it doesn't catch everything, it does help. Use unit tests. > I'm familiar > with things like pychecker, but it seems to be reporting a lot of issues > that aren't issues. You may find those useful but they are not a substitute for unit tests. > For example, I have a world module which is the core of > the engine; it handles players, as well as keeps tracks of all rooms that > are loaded in the game and that. Because player and world would have > circular imports, I just pass the world object into player functions like > logon/create. Pychecker tells me that the world parameter (which is a local > var at that point) shadows the world variable in world; world is a > singleton, so when you import world it just has a world = World() at the > bottom of the module. I would let the main script import World and create the world instance rather than placing a global variable in the world module. > > also: I have the following code: > logging.basicConfig(filename=path.join("logs", "mud.log"), > level=logging.DEBUG) > logger = logging.getLogger(__name__) > logger.addHandler(logging.StreamHandler()) > I like it displaying to stderr since usually when I'm doing this I'm in > screen bouncing back and forth between the output and the tt++ session, but > right now I can't get a couple of things; I'm not sure how to set it to log > and all other messages to stderr as I did for the file, and I'd like to use > a rotating log handler so that it'll rotate when the files are say above 16 > KB or something. Is it possible to do something like this; perhaps make it > compress the file before it writes to disk, or call a command to do so, so > that it wouldn't hang the entire mud while it compresses? Use a standard system tool to manage your server logs. For example logrotate(8) >From the manpage: ''' logrotate is designed to ease administration of systems that generate large numbers of log files. It allows automatic rotation, compression, removal, and mailing of log files. Each log file may be handled daily, weekly, monthly, or when it grows too large. ''' Oscar -- http://mail.python.org/mailman/listinfo/python-list
