Attached is a little C++ module that fetches the terminal capability string for turning off all attributes and runs it through tparm(). (All this is done in a static Ctor of a class without init function, but never mind.)

Compile with:
g++ -c testlib.cc
g++ testlib.o -o testlib.so -shared -Wl,-soname,testlib.so -lncurses

On SuSE Linux 10.1 (and older), I get the expected behavior:

Python 2.4.2 (#1, Oct 13 2006, 17:11:24) 
[GCC 4.1.0 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Dump of instance: 1b 5b 30 6d
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: dynamic module does not define init function (inittestlib)
>>> 

However, on SuSE Linux 10.2, tparm creates a NULL pointer:
Python 2.5 (r25:51908, Jan  9 2007, 16:59:32) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import testlib
Terminal is "xterm"
Dump of sgr0: 1b 5b 30 6d
Rats! tparm made a NULL pointer!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (inittestlib)
>>> 

Why, oh why?

I suspect that this is a duplicate of Bug [1548092].
Note that, there it is asserted that tparm returns NULL on certain invalid strings.
That does not seem to be true. It returns NULL for valid trivial strings, too.

I fail to see the bug. The exception precisely describes the error in your code

ImportError: dynamic module does not define init function (inittestlib)

Why do you expect any meaningful behavior in the presence of this error? Your shared library isn't an extension module.

If you think it is related to #1548092, please try out the subversion trunk, which has fixed this bug.

The error message about the undefined init function is a red herring. The example is actually a stripped-down testcase from a much larger Boost.Python module, which of course does have an init function. The point here is the NULL pointer returned by tparm.

Can you test with 2.5 from SVN and confirm your program works in the complete context?

Sorry, I cannot do that test anytime soon.
(I've not enough time and my company doesn't let me access your SVN.)

I can't help with the time factor, but I can with the access to svn.  You can download a snapshot here:

http://svn.python.org/snapshots/python25.tar.bz2

There are snapshots for the trunk as well as the active release branch.

So if you can get a little free time, it would be great if you could download the tarball and test.  Thanks.

I'll close this unless someone can confirm for 2.6.

I just tried Python 2.6 (r26:66714, Feb 21 2009, 05:33:00) from SUSE
Linux Enterprise Server 11 (i586) and it didn't fail. This appears to
have been fixed, somehow.

Thanks, Richard!

If someone confirms it, please reopen.