[Python-Dev] RE: [Python-checkins] python/dist/src/Objects typeobject.c, 2.244, 2.245
Guido van Rossum
guido at python.org
Thu Oct 9 00:43:20 EDT 2003
More information about the Python-Dev mailing list
Thu Oct 9 00:43:20 EDT 2003
- Previous message: [Python-Dev] RE: [Python-checkins] python/dist/src/Objects typeobject.c, 2.244, 2.245
- Next message: [Python-Dev] Re: RE: [Python-checkins] python/dist/src/Objectstypeobject.c, 2.244, 2.245
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> 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/)
- Previous message: [Python-Dev] RE: [Python-checkins] python/dist/src/Objects typeobject.c, 2.244, 2.245
- Next message: [Python-Dev] Re: RE: [Python-checkins] python/dist/src/Objectstypeobject.c, 2.244, 2.245
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list