[Python-3000-checkins] r57494 - python/branches/py3k/Objects/unicodeobject.c

[Neal Norwitz]

On 8/26/07, Guido van Rossum <guido at python.org> wrote:
> It was there because it's part of
>
> if (result == 0) { ... }
> else if (result == 1) { ... }
> else { assert(result == 2); ... }
>
> However the "..." in the last block contains declarations so the
> assert was moved below the declarations, and, worse, one of the
> declarations redefines 'result' (as a PyObject * initialized to NULL).
> So as soon as result==2 you'd get the failing assert.

Ah, I see.  I didn't realize that the result in the local block
shadowed another result.  I will fix that and add back in the assert
so it makes sense.

> I think the assert serves a purpose. Perhaps a better solution would be to add
>
> assert(0 <= result && result <= 2);
>
> right after the place where the original result is computed.

Yes, I like that better too.

> (BTW the name MarkupIterator_next confused me for a while until I
> remembered about stringlib. I think that after this has been
> backported to 2.x, we should factor out the stringlib stuff so it's
> just part of unicodeobject.c. Or it needs to use a better naming
> convention.)

I haven't had time to review this patch yet. :-(

Refactoring stringlib to be part of unicodeobject makes sense assuming
stringobject goes away.  The reason stringlib was there IIUC was to
support (share code for) both stringobject and unicodeobject.

n