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 lemburg
Recipients Arfrever, amaury.forgeotdarc, belopolsky, ezio.melotti, jafo, lemburg, loewis, ronaldoussoren, vstinner
Date 2010-12-07.18:11:06
SpamBayes Score 3.8237746e-12
Marked as misclassified No
Message-id <>
In-reply-to <>
Alexander Belopolsky wrote:
> Alexander Belopolsky <> added the comment:
> On Tue, Dec 7, 2010 at 12:44 PM, Marc-Andre Lemburg
> <> wrote:
> ..
>> * Rather than just patching in error handling code, please consider
>> removing use of those APIs and replace their calls with something
>> more appropriate, e.g. using a parser API.
> Yes, that's what I started doing in the "a" patch.  I am not sure what
> you mean by "a parser API." 

PyArg_Parse() et al. See the discussion earlier on this ticket.

> There are several places where conversion
> is either unnecessary or an encoded string is already available.  See
> _elementtree.c.

If the API is not needed at all, even better.

>> * When ignoring errors from the API, you have to clear the exception.
>> This is missing in a couple of places in the patch, e.g. in pyexpat.c
> Right.  On the other hand, this is very similar to xmlparser_getattro
> in _elementtree.c and I think should be handled the same way.

Not sure what you mean here. If you ignore errors and don't clear
the exception, it will pop up at some later point in processing
and that's generally very confusing.

>> * Please also remove hacks like these:
>> +#define CMP PyUnicode_CompareWithASCIIString
>> +        if (CMP(nameobj, "entity") == 0)
> What do you consider a hack?  The use of
> PyUnicode_CompareWithASCIIString() or the shortening macro?

The shortening macro.
Date User Action Args
2010-12-07 18:11:08lemburgsetrecipients: + lemburg, loewis, jafo, ronaldoussoren, amaury.forgeotdarc, belopolsky, vstinner, ezio.melotti, Arfrever
2010-12-07 18:11:06lemburglinkissue6697 messages
2010-12-07 18:11:06lemburgcreate