Hello there. Yesterday I posted a feature request, http://bugs.python.org/issue3582, along with a patch. It provides platform specifict TLS functions on windows. Implementing it I came across the strange semantics of PyThread_set_key_value(). If a value has been set previously, it will ignore the set. This is most unusual, and I had to make two TLS calls in the NT version to emulate this behaviour. This behaviour is mentioned in pystate.c: The only situation where you can legitimately have more than one thread state for an OS level thread is when there are multiple interpreters, when: a) You shouldn't really be using the PyGILState_ APIs anyway, and: b) The slightly odd way PyThread_set_key_value works (see comments by its implementation) means that the first thread state created for that given OS level thread will "win", which seems reasonable behaviour. */ Now, this seems to be the only place where this is required, but I fail to see how even in this scenario it makes sense. As a) code says, you shouldn't be using the GIL api anyway, and it will undoubtebly create problems elsewhere if sticking the thread state into TLS fails silently. Changing this odd behaviour of PyThread_set_key_value () is trivial and would make it easier to use native TLS functions on other platforms. Any thoughts? K