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 belopolsky
Recipients Arfrever, amaury.forgeotdarc, belopolsky, ezio.melotti, jafo, lemburg, loewis, ronaldoussoren, vstinner
Date 2010-12-07.18:06:07
SpamBayes Score 1.6096833e-09
Marked as misclassified No
Message-id <AANLkTimc0OeKJR-St6GOSfJEorXRM4+5HDUhwh6eM6SU@mail.gmail.com>
In-reply-to <4CFE726F.3080506@egenix.com>
Content
On Tue, Dec 7, 2010 at 12:44 PM, Marc-Andre Lemburg
<report@bugs.python.org> 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."  There are several places where conversion
is either unnecessary or an encoded string is already available.  See
_elementtree.c.

> * 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.

> * 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?
History
Date User Action Args
2010-12-07 18:06:15belopolskysetrecipients: + belopolsky, lemburg, loewis, jafo, ronaldoussoren, amaury.forgeotdarc, vstinner, ezio.melotti, Arfrever
2010-12-07 18:06:07belopolskylinkissue6697 messages
2010-12-07 18:06:07belopolskycreate