Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
final question: logging to stdout and updating files
39 views
Skip to first unread message
Littlefield, Tyler
Oct 3, 2012, 11:11:29 PM10/3/12
to Python
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'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. 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. I'm familiar with things like pychecker, but it seems to
be reporting a lot of issues that aren't issues. 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.
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?
Thanks, and sorry again for all the questions.
--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.
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'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. 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. I'm familiar with things like pychecker, but it seems to
be reporting a lot of issues that aren't issues. 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.
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?
Thanks, and sorry again for all the questions.
--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.
Ramchandra Apte
Oct 4, 2012, 3:53:49 AM10/4/12
to Python
Ramchandra Apte
Oct 4, 2012, 3:53:49 AM10/4/12
to comp.lan...@googlegroups.com, Python
On Thursday, 4 October 2012 08:41:35 UTC+5:30, Littlefield, Tyler wrote:
Oscar Benjamin
Oct 4, 2012, 5:27:19 AM10/4/12
to Littlefield, Tyler, Python
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
> 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?
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.
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.
> I'm familiar
> with things like pychecker, but it seems to be reporting a lot of issues
> that aren't issues.
> 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.
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?
>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
Ramchandra Apte
Oct 4, 2012, 9:34:28 AM10/4/12
to Python
On Thursday, 4 October 2012 08:41:35 UTC+5:30, Littlefield, Tyler wrote:
^0 http://docs.python.org/dev/library/logging.handlers.html#baserotatinghandler
"Optimize code always even if it causes bugs" - Ramchandra Apte, 2001-
Ramchandra Apte
Oct 4, 2012, 9:34:28 AM10/4/12
to comp.lan...@googlegroups.com, Python
On Thursday, 4 October 2012 08:41:35 UTC+5:30, Littlefield, Tyler wrote:
Steven D'Aprano
Oct 4, 2012, 10:00:26 AM10/4/12
to
On Thu, 04 Oct 2012 06:34:28 -0700, Ramchandra Apte wrote:
> "Optimize code always even if it causes bugs" - Ramchandra Apte, 2001-
Well, you've just added yourself into my list of people whose advice
> "Optimize code always even if it causes bugs" - Ramchandra Apte, 2001-
should always be ignored.
That is *terrible* advice. But if you insist on following it, you can
optimize *any* Python program to this:
# === start code ===
pass # this line is optional
# === end code ===
There you go. The most heavily optimized, fastest Python program in
existence. Sure, it has a few bugs, but boy is it fast!!!
--
Steven
Chris Angelico
Oct 4, 2012, 10:27:34 AM10/4/12
to pytho...@python.org
On Fri, Oct 5, 2012 at 12:00 AM, Steven D'Aprano
<steve+comp....@pearwood.info> wrote:
> That is *terrible* advice. But if you insist on following it, you can
> optimize *any* Python program to this:
>
> # === start code ===
> pass # this line is optional
> # === end code ===
>
>
> There you go. The most heavily optimized, fastest Python program in
> existence. Sure, it has a few bugs, but boy is it fast!!!
Not many bugs though! I ran it in my Python 5.2.7 for GNU/Windows
<steve+comp....@pearwood.info> wrote:
> That is *terrible* advice. But if you insist on following it, you can
> optimize *any* Python program to this:
>
> # === start code ===
> pass # this line is optional
> # === end code ===
>
>
> There you go. The most heavily optimized, fastest Python program in
> existence. Sure, it has a few bugs, but boy is it fast!!!
256-bit (err, yeah, I borrowed Guido's time machine but had the silly
thing in reverse... oops) and it worked perfectly, except that
indentation has moved from "significant" to "mandatory". When I added
the necessary 5 space indent at the beginning, it correctly created
world peace, ensured that Australia won the next Test Match, and then
printed "Hello, world!\n" to stdout. Unfortunately, a bug in your "end
code" comment meant that the peace it created was by wiping out all
life, but that's pretty minor in the scheme of things.
Optimization really is that important, folks!
ChrisA
may need to schedule surgical detongueing of his cheek
Steven D'Aprano
Oct 4, 2012, 10:52:43 AM10/4/12
to
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.
> 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?
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.
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.
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.
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
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
Prasad, Ramit
Oct 4, 2012, 6:36:02 PM10/4/12
to pytho...@python.org
Chris Angelico wrote:
> Sent: Thursday, October 04, 2012 9:28 AM
> To: pytho...@python.org
> Subject: Re: final question: logging to stdout and updating files
wins the Test Match....wait, do we even have a cricket team?
>
> Optimization really is that important, folks!
>
> ChrisA
> may need to schedule surgical detongueing of his cheek
Think we could get a group rate for c.l.p?
Ramit
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
> Sent: Thursday, October 04, 2012 9:28 AM
> To: pytho...@python.org
> Subject: Re: final question: logging to stdout and updating files
> > That is *terrible* advice. But if you insist on following it, you can
> > optimize *any* Python program to this:
> >
> > # === start code ===
> > pass # this line is optional
> > # === end code ===
> >
> >
> > There you go. The most heavily optimized, fastest Python program in
> > existence. Sure, it has a few bugs, but boy is it fast!!!
>
> > optimize *any* Python program to this:
> >
> > # === start code ===
> > pass # this line is optional
> > # === end code ===
> >
> >
> > There you go. The most heavily optimized, fastest Python program in
> > existence. Sure, it has a few bugs, but boy is it fast!!!
>
> Not many bugs though! I ran it in my Python 5.2.7 for GNU/Windows
> 256-bit (err, yeah, I borrowed Guido's time machine but had the silly
> thing in reverse... oops) and it worked perfectly, except that
> indentation has moved from "significant" to "mandatory". When I added
> the necessary 5 space indent at the beginning, it correctly created
> world peace, ensured that Australia won the next Test Match, and then
> printed "Hello, world!\n" to stdout. Unfortunately, a bug in your "end
> code" comment meant that the peace it created was by wiping out all
> life, but that's pretty minor in the scheme of things.
Python is a product for Americans! ;) It should ensure America
> 256-bit (err, yeah, I borrowed Guido's time machine but had the silly
> thing in reverse... oops) and it worked perfectly, except that
> indentation has moved from "significant" to "mandatory". When I added
> the necessary 5 space indent at the beginning, it correctly created
> world peace, ensured that Australia won the next Test Match, and then
> printed "Hello, world!\n" to stdout. Unfortunately, a bug in your "end
> code" comment meant that the peace it created was by wiping out all
> life, but that's pretty minor in the scheme of things.
wins the Test Match....wait, do we even have a cricket team?
>
> Optimization really is that important, folks!
>
> ChrisA
> may need to schedule surgical detongueing of his cheek
Ramit
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
Mark Lawrence
Oct 5, 2012, 4:11:22 AM10/5/12
to pytho...@python.org
On 04/10/2012 15:27, Chris Angelico wrote:
> ensured that Australia won the next Test Match
>
> ensured that Australia won the next Test Match
>
> ChrisA
> may need to schedule surgical detongueing of his cheek
>
I'll arrange the cheek detonguing very cheaply after a comment like that :)
> may need to schedule surgical detongueing of his cheek
>
--
Cheers.
Mark Lawrence.
Mark Lawrence
Oct 5, 2012, 4:19:31 AM10/5/12
to pytho...@python.org
On 04/10/2012 23:36, Prasad, Ramit wrote:
>
> Python is a product for Americans! ;) It should ensure America
> wins the Test Match....wait, do we even have a cricket team?
ChrisA could have been talking rugby, your rugby union team isn't't too
>
> Python is a product for Americans! ;) It should ensure America
> wins the Test Match....wait, do we even have a cricket team?
bad for a bunch of amateurs, some of whom had to take unpaid leave to
play in the world cup. I don't think there's any rugby league sides in
the USA. Then there's speedway and...?
>
>>
>> Optimization really is that important, folks!
>>
>> ChrisA
>> may need to schedule surgical detongueing of his cheek
>
>> may need to schedule surgical detongueing of his cheek
>
> Think we could get a group rate for c.l.p?
I'm sure that with some appropriate grovelling the PSF could arrange
this. Perhaps fly everybody to the UK for PyCon and get the surgery
done on the NHS at the same time.
>
> Ramit
>
--
Cheers.
Mark Lawrence.
Ramchandra Apte
Oct 5, 2012, 9:32:28 AM10/5/12
to
This email is subject to important disclosures available at loobafoobajo.ke/legal.html
LOOBA FOOBA JOKE COMPANY MAKES NO WARRANTIES ABOUT THIS EMAIL
Read at your risk - you may die from reading this email. ;-P
0 new messages