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 -- http://mail.python.org/mailman/listinfo/python-list
