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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
