Message 152842 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	kumma
Recipients	amaury.forgeotdarc, belopolsky, brian.curtin, ezio.melotti, kumma, meador.inge, vinay.sajip
Date	2012-02-08.09:27:52
SpamBayes Score	3.4633407e-13
Marked as misclassified	No
Message-id	<CANYHms1W8F6-mk89AYe+H8CjQ9OD84fcqNvwONUqOBCO3hKixQ@mail.gmail.com>
In-reply-to	<1314714480.92.0.730814291982.issue9041@psf.upfronthosting.co.za>

Content
Could we overcome these issues by some kind of exception inheritance? On Tue, Aug 30, 2011 at 5:28 PM, Meador Inge <report@bugs.python.org> wrote: > > Meador Inge <meadori@gmail.com> added the comment: > > That is a good question. While it is true that errors other than 'PyExc_OverflowError', will be mapped onto a 'TypeError' I don't think that is a bad thing. Any errors that come out of 'PyFloat_AsDouble' should be handled on a case-by-case basis and not blindly passed back out the call chain. Otherwise, we may end up passing back errors (which are who knows what) that make sense for a caller of 'PyFloat_AsDouble', but not for callers of 'g_set'. > > Also, the interface would become variable, meaning that whenever 'PyFloat_AsDouble' introduces new exceptions, then this code would too, which would lead to a somewhat unpredictable interface for callers of 'g_set'. > > ---------- > > _______________________________________ > Python tracker <report@bugs.python.org> > <http://bugs.python.org/issue9041> > _______________________________________

Could we overcome these issues by some kind of exception inheritance?

On Tue, Aug 30, 2011 at 5:28 PM, Meador Inge <report@bugs.python.org> wrote:
>
> Meador Inge <meadori@gmail.com> added the comment:
>
> That is a good question.  While it is true that errors other than 'PyExc_OverflowError', will be mapped onto a 'TypeError' I don't think that is a bad thing.  Any errors that come out of 'PyFloat_AsDouble' should be handled on a case-by-case basis and not blindly passed back out the call chain.  Otherwise, we may end up passing back errors (which are who knows what) that make sense for a caller of 'PyFloat_AsDouble', but not for callers of 'g_set'.
>
> Also, the interface would become variable, meaning that whenever 'PyFloat_AsDouble' introduces new exceptions, then this code would too, which would lead to a somewhat unpredictable interface for callers of 'g_set'.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue9041>
> _______________________________________

History
Date	User	Action	Args
2012-02-08 09:27:53	kumma	set	recipients: + kumma, vinay.sajip, amaury.forgeotdarc, belopolsky, ezio.melotti, brian.curtin, meador.inge
2012-02-08 09:27:53	kumma	link	issue9041 messages
2012-02-08 09:27:52	kumma	create