Message 108384 - 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	skrah
Recipients	eric.smith, loewis, pitrou, r.david.murray, skrah, srid
Date	2010-06-22.14:27:14
SpamBayes Score	0.005397637
Marked as misclassified	No
Message-id	<1277216836.46.0.599833830018.issue9020@psf.upfronthosting.co.za>
In-reply-to

Content
Re: EOF checking in Py_ISXXX() for consistency with C functions. After reflecting on this a bit I think it's ultimately not a good idea. While it is possible to do the EOF check, the macros would then take either an int in [EOF, 0-UCHAR_MAX] or a signed/unsigned char. This would be another inconsistency with the C functions, which are not supposed to take a signed char. I checked every usage of Py_IS* in the tree and this is an isolated case. So I think it's better to do the check explicitly and add a comment to the Py_IS* macros. Does the patch look good?

Re: EOF checking in Py_ISXXX() for consistency with C functions.

After reflecting on this a bit I think it's ultimately not a good
idea. While it is possible to do the EOF check, the macros would
then take either an int in [EOF, 0-UCHAR_MAX] or a signed/unsigned
char. This would be another inconsistency with the C functions,
which are not supposed to take a signed char.


I checked every usage of Py_IS* in the tree and this is an isolated
case. So I think it's better to do the check explicitly and add a
comment to the Py_IS* macros.


Does the patch look good?

History
Date	User	Action	Args
2010-06-22 14:27:17	skrah	set	recipients: + skrah, loewis, pitrou, eric.smith, r.david.murray, srid
2010-06-22 14:27:16	skrah	set	messageid: <1277216836.46.0.599833830018.issue9020@psf.upfronthosting.co.za>
2010-06-22 14:27:15	skrah	link	issue9020 messages
2010-06-22 14:27:14	skrah	create