RetroSearch Browse

Thu Oct 9 00:43:20 EDT 2003 · https://mail.python.org/pipermail/python-dev/2003-October/038609.html

> Guido van Rossum <guido at python.org>:
> 
> > Maybe PyBool_FromLong() itself could make this unneeded by adding
> > something like
> > 
> >     if (ok < 0 && PyErr_Occurred())
> >         return NULL;
> > 
> > to its start?

[Greg Ewing]
> Not sure if it would be a good idea to encourage reliance
> on one API function doing error checking on behalf of others.

Well, most functions in the abstract.c file already do this.

And it would actually *catch* bugs -- in fact, the one that Raymond
found in descrobject.c originally had

    return PyInt_FromLong(PySequence_Contains(pp->dict, key));

which was not checking for errors from PySequence_Contains().

> I can see someone coming along later and adding some code
> in between whatever returned the result and the PyBool_FromLong
> call, not realising that doing so would upset the error
> checking.

Well, they would have to miss two clues: the documented behavior of
PyBool_FromLong() and the fact that whatever produced the value passed
in could fail.  I'm not sure if that's a big worry, especially since
this is typically in dead-simple code.

OTOH, explicit is better than implicit.

--Guido van Rossum (home page: http://www.python.org/~guido/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-October/038609.html below:

[Python-checkins] python/dist/src/Objects typeobject.c, 2.244, 2.245