[Python-Dev] Trial balloon: microthreads library in stdlib (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Tue Feb 13 11:39:23 CET 2007

Steve Holden schrieb:

The only things that concern me are a) whether it could make sense to add Stackless in bits and pieces and b) whether the BDFL (or even the developer community en masse) would object in principle, thereby rendering such efforts useless.

I think I need to try again. The 'developer community en masse' does not have a single voice, so it won't object. Not sure about the BDFL, but I personally don't object 'to a change like that' 'in principle', primarily because I don't know what the change is.

I know I'm almost certainly object to the change 'incorporate Stackless Python into Python as-is', because history shows that any change of that size would need multiple iterations until it was acceptable (despite the code being in-use for multiple years). Very few people can get away with getting their code unedited into Python (ctypes and elementtree being the most prominent examples); in these cases, I could accept what I consider flaws in the code because: a) the authors promised to maintain the code, and react to actual bug reports, and b) these come as extension modules, so it's easy to ignore them if you don't like them.

My (limited) understanding is that with Stackless installed all existing programs that don't import stackless should continue to run unchanged. If that's true then it seems to me it would be a desirable addition as long as maintainability wasn't compromised. I suppose only the patches will allow a sensible judgment on that issue.

My understanding is that incorporating Stackless will reduce the portability: it cannot work on certain platforms, and even for platforms it works on, it cannot work with certain compilers or compiler switches (the Windows SEH being the primary example; the SPARC register stack another one - although this might now be supported through assembler code). On platforms where it isn't supported, it still may compile, but might crash the interpreter when used.

Please understand that this is from a shallow inspection a few years ago (actually, a description of the working mechanics that Christian gave me). It would make me feel uncomfortable if Python had modules that may randomly crash the interpreter, and there is no procedure to tell beforehand whether a certain applications is supported or not.

Also, I would not like to see modules that monkey-patch other modules in the standard library. If socket.connect is to behave differently, the code that makes that so should be in socket.connect, and the documentation of socket.connect should state that it has that modified behavior. Of course, people may object to massive library changes of the nature "if running in stackless mode, this library routine behaves differently".

Regards, Martin

More information about the Python-Dev mailing list