final question: logging to stdout and updating files

[Steven D'Aprano]

On Wed, 03 Oct 2012 21:11:29 -0600, Littlefield, Tyler wrote:

> 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? 

Oh, about as hard as writing a program.

What sort of files? What does your engine do? How does it do it? Without 
knowing the answers to these questions, how can we possibly tell you how 
hard it will be to reload them?

Detecting changed files is easy. If you google for "python monitor 
directory" and similar terms, you will find a metric tonne of solutions.

Having your engine reload files is entirely up to you: it's your engine, 
it will be as trivial or as difficult as you make it be.


> I'm also curious how hard it would be to build in some error recovery. 

How long is a piece of string? Again, that depends on you. If you design 
your application with error recovery in mind, it could be trivial. If you 
don't, it could be impossible.


> For example right now when an
> exception occurs, the player is sometimes just left hanging. 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. 

Sure, compiler-time checks can sometimes be useful. But in general, they 
tend to only detect the most trivial errors, syntax errors (Python does 
that too) and type errors.

In Python, the usual answer is to concentrate on writing good unit tests. 
Good unit tests will test far more than the compiler ever could, and will 
pay for themselves a hundred times over.


> I'm familiar with things like pychecker, but it seems to
> be reporting a lot of issues that aren't issues.

Pychecker, like other linters, don't just report fatal errors. They may 
also report *suspicious code* which may indicate an error, poor 
techniques, unused code, bad naming conventions, or other examples of 
poor style. You should be able to turn off such warnings.


> 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

Right there is a terrible *code smell*.

http://www.joelonsoftware.com/articles/Wrong.html

Maybe you have a good reason for a circular import, but alarm bells are 
ringing. Rather than having:

# world.py
import player

# player.py
import world

which leads to all sorts of complications, it is usually better to have a 
single module import both world and player and then combine them as 
needed.


-- 
Steven