but do we want this sort of code in Python?

Since I proposed a more primitive approach to solve the same problem (which you had postponed), I'm obviously in favour of that patch.

Is this sort of hack, however clever, going to some back and bite us?

I can't see why. The code is quite defensive: If the data structures don't look like what it expects, it gives up and claims it can't find the version of the python dll used by this module. So in worst case, we get what we have now. My only concern is that it assumes the HMODULE is an address which can be dereferenced. If there was some MS documentation stating that this is guaranteed in Win32, it'd be fine. If it is merely established fact that all Win32 current implementations implement HMODULE that way, I'd rather see a __try/__except around that - but that would only add to the defensive style of this patch. A hack is required since earlier versions of Python did not consider this problem. I don't know whether python20.dll will behave reasonably when loaded into Python 2.1 next year - was there anything done to address the "uninitialized interpreter" problem?

if people like it, is this feature something we can squeeze in for 2.0?

I think this patch will have most value if applied to 2.0. When 2.1 comes along, many people will have been bitten by this bug, and will know to avoid it - so it won't do that much good in 2.1. I'm not looking forward to answering all the help@python.org messages to explain why Python can't deal with versions properly, so I'd rather see these people get a nice exception instead of IDLE silently closing all windows [including those with two hours of unsaved work]. Regards, Martin P.S db3l is David Bolen, see http://sourceforge.net/users/db3l.