Interface and duck typing woes

Joe Junior joe.fbs.junior at gmail.com
Thu Aug 29 10:11:38 EDT 2013


On 29 August 2013 10:07, Chris Angelico <rosuav at gmail.com> wrote:
> Hmm. l don't know of any good articles off-hand. But what I'm talking
> about is simply developing the skill of reading exceptions, plus a few
> simple things like knowing where it's appropriate to catch-and-log;
> sometimes, what that means is actually writing some code to (for
> example) email you whenever there's an exception, but more likely it
> means writing no code at all, and just looking at STDERR of your live
> usage. Works really well for >95% of Python scripts.
>
> The most important thing to consider is: What happens if my code
> doesn't run all the way through? Is it safe for this to run part way,
> then bomb with an exception? For many scripts, it's pretty easy: fix
> the problem and rerun the script, and it'll completely rewrite its
> output file. For others, this is a good reason for putting all your
> "real data" into a transactional database - you begin a transaction at
> the top, don't commit till the end, and if an exception kills your
> script, your transaction will be rolled back. I have a system for
> patching our database based on a script (written in Pike, not Python,
> but the same applies); if I have any sort of critical failure in the
> patch script, it'll bomb out as soon as I test it - but since I use
> PostgreSQL, all that DDL (eg "ALTER TABLE") is covered by
> transactional integrity (which it isn't with MySQL - another reason to
> be wary of MySQL), so my patch will be backed out, and I can fix it
> and start over. I don't need to have a Look Before You Leap approach
> to database changes - I can simply do stuff, and if it crashes, all's
> well. (That same script also has a system for catching errors at a
> mid-level point that means that the process doesn't terminate when
> there's an error; it supports full code reload, so once I fix the
> patch, I send the process a SIGHUP and it fetches from disk again.)
> *That* is error handling the safe way.
>

Oh, I get it! Thanks.



More information about the Python-list mailing list