Problem: new type in Python 2.2

[Tim Peters]

[Dave Kuhlman]
> I've implemented a new Python type (in C). It's based on
> Objects/xxobject.c in the source code distribution.  It implements
> a wrapper for a compiled XSLT stylesheet and is part of the Python
> support for libxslt.  (See http://www.rexx.com/~dkuhlman)
>
> It no longer works with Python 2.2.
>
> Here is the finger-print of the error:
>
>
>     o
>     o
>     o
>   File "test_to_file_compiled.py", line 28, in translate
>       for stem in fileStems:
> TypeError: argument 2 must be string, not libxslt_stylesheet
>
>
> Where:
>
>     libxslt_stylesheet is the Python type that I have implemented.
>
>     fileStems is a list of strings.
>
> The error occurs when the for statement is exited, i.e. after all
> the iterations have been completed.
>
> This error message does not make too much sense to me.

Cheer up, it makes no sense at all <wink>.  This is usually a symptom of a
function in an extension module setting an error condition but neglecting to
return NULL (or whatever the proper error return is in context).  A common
way for that to happen is for an extension to neglect to check the return of
an API function *it* calls for errors (every call must be checked for an
error return, and every error must be passed on or explictly cleared -- you
can never skip these checks).  As a result, the main interpreter loop may
miss the error at the time it occurs (the extension lied about whether an
error did occur), and not notice until some later (and by-now irrelevant)
opcode checks PyErr_Occurred() and picks up a stale error message.  In
particular, the opcodes involved with for-loop setup and teardown make
PyErr_Occurred() checks, as part of distinguishing a normal StopIteration
loop exit from an unexpected exception.

If you build a debug-mode Python, the interpreter loop makes extra checks
after each opcode to try to detect whether someone just lied about the error
state.  This will point out the mistake closer to where it's really
happening.  If mistake is found, of these msgs is printed to stderr:

		"XXX undetected error\n"
		"XXX undetected error (why=%d)\n"

> ...
> I can't find this error message in the Python 2.2 source.

Me neither -- and that's more evidence that an extension is involved.  The
Python core is the least likely source (historical truth -- it's *almost*
never to blame for these things, simply because the core code is so heavily
exercised by so many people that such mistakes don't survive to see a final
release).  It could be in your extension, or in any other extension you're
using.

> ...
> This error occurs when I run Python 2.2.  It does not occur when I
> run Python 2.1.

Probably irrelevant once the true cause is known.  Mistakes can go
undetected by accident.  API functions that didn't used to raise errors in
some endcases may also start to, so sloppy use of API functions (not
checking for error returns) can also go unpunished by accident.

> ...
> Are there some steps that I must go through ...?

Good odds of quick success:  find the function(s) in the extensions you use
that create the message in question, and stare at their callers until you
find the one that's improperly dealing with an error return.