final question: logging to stdout and updating files
Steven D'Aprano
steve+comp.lang.python at pearwood.info
Thu Oct 4 10:52:43 EDT 2012
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
More information about the Python-list
mailing list