Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Chris Angelico <rosuav@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: raise None
Date: Fri, 1 Jan 2016 09:48:33 +1100
Lines: 62
Message-ID: <mailman.125.1451602117.11925.python-list@python.org>
References: <56847239$0$1590$c3e8da3$5496439d@news.astraweb.com> <mailman.96.1451522295.11925.python-list@python.org> <5684842a$0$1596$c3e8da3$5496439d@news.astraweb.com> <mailman.97.1451526250.11925.python-list@python.org> <5684aa1a$0$1602$c3e8da3$5496439d@news.astraweb.com> <mailman.107.1451564424.11925.python-list@python.org> <56854b49$0$1615$c3e8da3$5496439d@news.astraweb.com> <CAPTjJmqP69E2JXOXchpZHNnyvF=t=rwU7cA7EQFB89_iPXvmYg@mail.gmail.com> <CAHVvXxRWhbztj=53gmqPdvF9B357591Kh=dYdKmCwtwM3HOgbw@mail.gmail.com> <85r3i2s776.fsf@benfinney.id.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
In-Reply-To: <85r3i2s776.fsf@benfinney.id.au>
Precedence: list
Xref: csiph.com comp.lang.python:101083

On Fri, Jan 1, 2016 at 7:18 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Oscar Benjamin <oscar.j.benjamin@gmail.com> writes:
>
>> Exactly. The critical technique is looking at the traceback and
>> splitting it between what's your code and what's someone else's.
>> Hopefully you don't need to look at steves_library.py to figure out
>> what you did wrong. However if you do need to look at Steve's code
>> you're now stumped because he's hidden the actual line that raises.
>
> +1.
>
> As best I can tell, Steven is advocating a way to obscure information
> from the traceback, on the assumption the writer of a library knows that
> I don't want to see it.
>
> Given how very often such decisions make my debugging tasks needlessly
> difficult, I'm not seeing how that's a desirable feature.

What Steven's actually advocating is removing a difference between
Python code and native code. Compare:

>>> class Integer:
...     def __add__(self, other):
...         if isinstance(other, list):
...             raise TypeError("unsupported operand type(s) for +:
'Integer' and 'list'")
...         return 5
...
>>> 7 + []
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'list'
>>> Integer() + []
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in __add__
TypeError: unsupported operand type(s) for +: 'Integer' and 'list'


The default int type is implemented in native code (C in CPython, Java
in Jython, etc). If the addition of an int and something else triggers
TypeError, the last line in the traceback is the last line of Python,
which is the caller. But since Integer is implemented in Python, it
adds another line to the traceback.

Would you advocate adding lines to the first traceback saying:
  File "longobject.c", line 3008, in long_add
  File "longobject.c", line 1425, in CHECK_BINOP

etc? It might be useful to someone trying to debug an extension
library (or the interpreter itself).  Or if it's acceptable to omit
the "uninteresting internals" from tracebacks, then why can't we
declare that some bits of Python code are uninteresting, too?

We already have the means of throwing exceptions into generators,
which "pretends" that the exception happened at that point. Why can't
we throw an exception out to the caller?

I think it's a perfectly reasonable idea, albeit only a small benefit
(and thus not worth heaps of new syntax or anything).

ChrisA