Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Marko Rauhamaa <marko@pacujo.net>
Newsgroups: comp.lang.python
Subject: Re: raise None
Date: Fri, 01 Jan 2016 02:29:41 +0200
Organization: A noiseless patient Spider
Lines: 22
Message-ID: <87mvsq2lca.fsf@elektro.pacujo.net>
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> <CAPTjJmpYYgcADquXfJdLWiHDBeGm2FF9FdLv_NZmaqv50=uuDw@mail.gmail.com> <mailman.127.1451604459.11925.python-list@python.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: mx02.eternal-september.org; posting-host="b7cb1518d23ec19d482dcc9c31d30fdd"; logging-data="31383"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/7ODk/UlcOVINDhZuhPPTS"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
Cancel-Lock: sha1:Hdax0JNgIzIpofUwQI0DC9zKMdA= sha1:FZVQq5xiqD0irlIdG40hRR5R0zA=
Xref: csiph.com comp.lang.python:101089

Ben Finney <ben+python@benfinney.id.au>:

> Chris Angelico <rosuav@gmail.com> writes:
>> What Steven's actually advocating is removing a difference between
>> Python code and native code.
>
> Sure, but his proposal is to move in the direction of *less* debugging
> information.
>
> If I could have the traceback continue into the C code and tell me the
> line of C code that raised the exception, *that's* what I'd choose.
>
> The debugging information barrier of the C–Python boundary is a
> practical limitation, not a desirable one. I think those barriers
> should be as few as possible, and don't agree with enabling more of
> them.

I think I agree with you. Don't check anything; let it crash and burn if
the input spec is violated.


Marko