

An underrated feature in Python 3 - ionelm
http://blog.ionelmc.ro/2014/08/03/the-most-underrated-feature-in-python-3/

======
erikb
What I don't understand about Python is why it's not printing the str() of the
variables in the corresponding lines of the traceback. About 95% of all
debugging starts with adding prints or logging messages before the lines
mentioned in the traceback. Or am I doing something wrong here (since 5
years...)?

~~~
mlader
I typically will throw in a debugger instead of a print statement if I'm
debugging locally.

import ipdb; ipdb.set_trace()

Then I'll explore the context variables and figure out what the hell is going
on.

~~~
est
I think 99.9999% experienced python devs do this.

Why can't PSF make it default?

At least some kind of commandline switch to break to last traceback context by
default. e.g.

python --debug my_code.py

~~~
the_real_bto
they did: python -m pdb my_code.py

------
the_mitsuhiko
To be honest. As cool as this feature is in the 1% of cases where I wanted it,
so annoying is it in 99% of all other cases. Tracebacks on Python 3 became a
lot more complex because very often exceptions are intentionally swallowed to
be reraised differently and they just mess up the traceback now.

For instance any custom collection that acts as a decorator will now generate
very large tracebacks.

I would have much preferred if the reraising with old traceback would have
been a feature you can enable per site where you raise.

~~~
Walkman
I don't understand what are you talking about. AFAIK, you don't have to
reraise the previous exception:

    
    
        In [1]: try:
           ...:     raise Exception('Something is wrong')
           ...: except Exception as e:
           ...:     raise
           ...:
        ---------------------------------------------------------------------------
        Exception                                 Traceback (most recent call last)
        <ipython-input-1-ef6cea2fccac> in <module>()
              1 try:
        ----> 2     raise Exception('Something is wrong')
              3 except Exception as e:
              4     raise
              5
    
        Exception: Something is wrong
    
        In [2]: try:
            raise Exception('Something is wrong with RERAISE')
        except Exception as e:
            raise e
           ...:
        ---------------------------------------------------------------------------
        Exception                                 Traceback (most recent call last)
        <ipython-input-2-c6729aaebd3d> in <module>()
              2     raise Exception('Something is wrong')
              3 except Exception as e:
        ----> 4     raise e
              5
    
        <ipython-input-2-c6729aaebd3d> in <module>()
              1 try:
        ----> 2     raise Exception('Something is wrong with RERAISE')
              3 except Exception as e:
              4     raise e
              5
    
        Exception: Something is wrong with RERAISE

~~~
the_mitsuhiko
> I don't understand what are you talking about. AFAIK, you don't have to
> reraise the previous exception:

Correct, and also you can explicitly suppress the other traceback now (3.2+)

I just wish it was the default unless you opted in. If I catch down an
exception and raise another one _I do not want the old one_. Only in very rare
cases am I interested in what lead to it. I have lots of hacks in Jinja2 now
to hide useless tracebacks that would only confuse users.

For instance a jinja context tries different dicts through a chain in
__getitem__. The naive implementation on Python 3 generates two nearly
equivalent tracebacks that are very confusing.

~~~
marcosdumay
If you don't want the older exception, why are you giving it to the
constructor of the new exception?

Just raise SomeErrorType("error message"), and it will not polute your
traceback. Raising SomeErrorType(anotherError) is there for when you care
about anotherError.

~~~
the_mitsuhiko
> If you don't want the older exception, why are you giving it to the
> constructor of the new exception?

Exceptions are chained automatically through the stracktrace and not because
they are passed to the constructor. By raising an exception from an exception
handler you automatically chain them.

------
aturek
I don't understand Python exceptions that well. But it's great to have the
pattern of maintaining the stack trace when re-raising an exception. Thanks
OP!

(In case anyone missed it)

    
    
        except foo.FooException as e:
            raise BarException, BarException(e), sys.exc_info()[2]

------
whalesalad
Had the pleasure of working with the author (Ionel) a few years back on some
Django projects. Always love reading his Python posts. Really inspiring
developer.

------
viraptor
Actually passing the exception is not required. Even if "e" is not an argument
to BarException, the behaviour is the same.

------
dragonwriter
Why is the current title ("An underrated feature in Python 3") neither the
original source title ("The most underrated feature in Python 3") or a title
more descriptive of the content (e.g., "Exception chaining in Python 3").

If we're going to get title changes, can we at least get _useful_ title
changes?

~~~
hueving
>If we're going to get title changes, can we at least get useful title
changes?

No. If the title changes were useful, what would we discuss on HN?

------
raldi
Can a moderator de-hype the title, please?

[Edit: thanks!]

~~~
ionelm
What title would you like ? What's exactly hyped ?

~~~
raldi
"The most underrated feature" is total hype. It's exactly the sort of thing
the Guidelines link at the bottom of every HN page says to remove.

Maybe, "Python 3 exception-handling improvement."

~~~
captainmuon
Hmm, it's just a figure of speach. "The most underrated feature" -> "I really
like this feature and think it deserves more attention."

Just like "the best programming language ever" -> "a programming language I am
really excited about, that fits my needs very well".

The hyperbole is not the problem IMO, it's the nondescriptiveness. I think the
title should have something about exception handling in it.

The enforcement of the Guidelines has been pretty arbitrary, and quite often
good (editorialized) titles have been turned back into something nondescript.
Or now the other way around, the original title is editorialized to be less
interesting. I think the most important criteria for a title are: does it get
across the topic of the link, and the target page author's intention?

