Awsome Python - chained exceptions

[Rick Johnson]

On Wednesday, February 13, 2013 12:58:46 AM UTC-6, Chris Angelico wrote:
> On Wed, Feb 13, 2013 at 1:47 PM, Rick Johnson wrote:
> >On Tuesday, February 12, 2013 12:15:29 AM UTC-6, Steven D'Aprano wrote:
> >> If you've ever written an exception handler, you've probably written a
> >> *buggy* exception handler:
> >>
> >> def getitem(items, index):
> >>     # One-based indexing.
> >>     try:
> >>         return items[index-1]
> >>     except IndexError:
> >>         print ("Item at index %d is missing" % index - 1)  # Oops!
> >>
> >>
> >> Unfortunately, when an exception occurs inside an except or finally
> >> block, the second exception masks the first, and the reason for the
> >> original exception is lost:
> >>
> >> py> getitem(['one', 'two', 'three'], 5)  # Python 2.6
> >> Traceback (most recent call last):
> >>   File "<stdin>", line 1, in <module>
> >>   File "<stdin>", line 6, in getitem
> >> TypeError: unsupported operand type(s) for -: 'str' and 'int'
> >
> > Which (by showing the offensive line) is quite clear to me.
> 
> No, the offending (not offensive) line is "return items[index-1]",
> which doesn't feature in your traceback at all. 

Do you realize that you are quoting DeAprano and not me? Whether you realize this fact or not, consider the next two questions.

  Q1: How could a line in the "try" block ever be considered
  offensive? Because it throws an error? Are you serious?
  
  Q2: Why would the line in the try block be shown as
  a "feature" of the traceback when the whole intent of
  exception handling is to hide the error in the try
  block! If you want to raise the exception in the try block
  then you place a naked raise statement in the exception
  block, BUT THEN, why even wrap the code in a try/except
  in the first damn place!?

Man, you and DeAprano must be cut from the same block; or more correctly, carved by the same shaky hand of a creator suffering the late-stage effects of Alzheimers disease.

> It DOES, however,
> feature in the Py3.1 double traceback (it's listed as line 4)..
> 
> > 1. You are using the print function (so we can assume you are using Python 3.x)
> 
> He is? Could just as easily be the print statement with a single
> argument, with unnecessary parentheses around that argument. Which, if
> I recall correctly, is one of the recommended approaches for making
> 2/3 bi-compatible code.

Really? 

Because if he did in-fact write the print statement using parenthesis (in some foolish attempt to make his code forward-compatible) that would mean i should add /another/ coding abomination to my earlier list of abominations. The proper method of using a forward compatible print function is by /importing/ the feature.

   from future import print_function

> No. Definitely not. Percent interpolation isn't going anywhere - core 
> devs have said so - and there are many occasions when it is at least
> as well suited to the task as .format() is. 

In other words: Screw consistency and to hell with the zen?

> Also, it's a notation
> that's well understood *across languages* and in a variety of message
> interpolation systems. Anyone who's worked with *any* of them will
> understand that %s inserts a string, %d a number (in decimal), etc,

Oh yes, because indexing the list of arguments in the format method is SO much more overhead! Heck, Python>=2.7 (read the docs for exact release number) will allow you to implicitly pass the index:

    print "{} is one more than {}".format("five", "four") # 3.something

...is equivalent to:

    print "{0} is one more than {1}".format("five", "four")
    
...but what about when you need to substitute the /same/ substring in more than one location? Using the old nasty interpolation you are foced to write this:

    print "Chris is a %s who is very %s-ish"%('troll', 'troll')
    
...ewwww yuck! String.format() to the rescue!

    print "Chris is a {0} who is very {0}-ish".format('troll')

In fact all of these posted examples work in Python>=2.7.

So the moral is: You can pass no indexes and the format method will intuit the indexes from their linear position in the string, or you can pass indexes and be explicit (plus you can reference a value more than once!), or you can choose one of the many other great options available of the format method. 

    http://docs.python.org/2/library/string.html#format-string-syntax

> etc. Granted, the exact details after that may change (eg Python has
> %r to emit the representation, while Pike uses %O for "any object",
> with similar notation), but the format specifiers and modifiers that
> came from C are fairly stable, readable, and compact.

The fact is that "str.format(args)" beats the pants off string interpolation any day and anybody arguing for keeping string interpolation is not thinking clearly (especially when they first claim consistency between languages and them expose that claim as a lie) and is also anti-pythonic! To continue to propagate foolish language designs simply because other people have been brainwashed by them is, well, foolish. Would you propagate propaganda using the same excuse?

> In what way is a trivial example like this improved by the use of
> format()? The ONLY thing I can think of is that, by forcing you to put
> parentheses around the argument,

You think the only difference between string.format() and string interpolation is parenthesis? Chris, just because you don't understand how to use str.format() (or interpolation!) correctly does not mean other python programmers are unable too.

> it avoids the issue from the original
> post, which is one of operator precedence - but that's something
> that's fairly easy to spot when you know what you're looking for, and
> is definitely not specific to string formatting.

So as you say: str.format() solves a bug in the code, but that is not enough excuse to stop using the old cryptic and bug inducing interpolation syntax. I see[1].

[1] Read as: "I see that you are a lost cause". Hopefully you will grow a brain and read the format docs, and then try to apply it in your code, then MAYBE you will understand why i support str.format as the only method to format a string.

PS: Why do keep posting email addresses on the list? Does your client not trim, or at least warn, about these?