final question: logging to stdout and updating files

Oscar Benjamin oscar.j.benjamin at gmail.com
Thu Oct 4 05:27:19 EDT 2012


On 4 October 2012 04:11, Littlefield, Tyler <tyler at 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



More information about the Python-list mailing list