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 meador.inge
Recipients amaury.forgeotdarc, belopolsky, brian.curtin, eric.araujo, ezio.melotti, kumma, meador.inge, vinay.sajip
Date 2011-08-30.14:27:59
SpamBayes Score 6.19481e-10
Marked as misclassified No
Message-id <1314714480.92.0.730814291982.issue9041@psf.upfronthosting.co.za>
In-reply-to
Content
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'.
History
Date User Action Args
2011-08-30 14:28:00meador.ingesetrecipients: + meador.inge, vinay.sajip, amaury.forgeotdarc, belopolsky, ezio.melotti, eric.araujo, brian.curtin, kumma
2011-08-30 14:28:00meador.ingesetmessageid: <1314714480.92.0.730814291982.issue9041@psf.upfronthosting.co.za>
2011-08-30 14:28:00meador.ingelinkissue9041 messages
2011-08-30 14:28:00meador.ingecreate