[Python-Dev] Trial balloon: microthreads library in stdlib

[Steve Holden]

Martin v. Löwis wrote:
> Richard Tew schrieb:
>> I can't point you to the posts, but I can point you to something
>> Christian has written on the subject which may indicate why
>> it was never actually submitted for inclusion.
>>
>> See "A Bit Of History"
>> http://svn.python.org/view/stackless/trunk/Stackless/readme.txt
>>
>> I have not talked to Christian about it but as the current maintainer
>> of Stackless I was under the impression that there was a complete
>> lack of interest in even considering it for integration.
> 
> I think this comes from a major misunderstanding of how free software
> works. This is not commercial software, so there is no "company
> agenda" that drives it forward. There are various contributors,
> each having their own agenda; for most of us, it's "scratch your
> own itches". Surely, the voices of people have varying significance
> (in Python, Guido is the BDFL, for example), but "there was a complete
> lack of interest in even considering" just cannot be true: clearly,
> some contributors and users *were* interested.
> 
> There were surely objections to the implementation strategy, and
> I also had objections to the specific execution of this
> implementation strategy, see http://tinyurl.com/27v23r
> 
> Now, the question is whose "job" it would have been to integrate
> Stackless to Python. Apparently, Christian tried to make it happen
> (see http://tinyurl.com/3bqe5d), although I'm still uncertain
> whether he ever got to a point where he said: "this is a patch,
> please review it" (of that, I can find no archives, as I said).
> 
> I find it understandable that nobody else took over to work
> on integrating it (although there is PEP 219, so apparently
> some people worked at some point on it).
> 
>  From my point of view, people suggesting to incorporate code
> as-is often misunderstand that it is not sufficient for the code
> to work in the applications were it is used. It must also be sound
> (i.e. work in some meaningful way also in cases for which it wasn't
>  designed), and it must be maintainable.
> 
> I can understand how discouraging it is when you see that your
> code "works" that then people object to incorporating it as-is.
> However, I believe the long-term quality of Python can only
> be guaranteed when careful review is applied to every change
> made, or else we will regret changes in the future (and indeed,
> Python 3000 would not have been necessary if no mistakes had
> been made).
> 
>> If addition of microthreading is being considered please consider
>> Stackless.  One reason why Stackless is not so popular is that
>> as a fork people shy away from it because it is not the main
>> version.  It would benefit Stackless to be integrated and I would
>> be willing to do any work involved to either integrate or maintain
>> it afterwards.
> 
> This is what I'm talking about: nothing "is" ever considered. Instead,
> individuals make contributions, individuals review them, and individuals
> support and object to changes. There is no abstract python-dev
> entity that likes or dislikes changes. Individuals have individual
> opinions.
> 
> Now, where is the SF patch that makes Stackless part of Python ?-)
> (and if you are serious about it, try to break it down into multiple
>  pieces, each individually correct and useful; start with one where
>  the effort isn't too big in case it gets rejected by BDFL
>  pronouncement)
> 
> I haven't reviewed the Stackless code in a while; last I looked,
> I found it was possible to crash the interpreter if you use it
> "incorrectly". I *personally* object to changes where it is easy
> to crash the interpreter, unless there is a clear specification
> when this may happen, and there is a systematic way to avoid that
> (this is the ctypes clause).
> 
Well given that ctypes has now been incorporated I suspect that the 
objections to Stackless might be different should a further integration 
"effort" materialise. I know that there's work in progress (and indeed 
almost complete) to put Stackless into 2.5, so it seems as though it 
might be practical to follow the approach you suggest.

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.

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.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb     http://del.icio.us/steve.holden
Blog of Note:          http://holdenweb.blogspot.com
See you at PyCon?         http://us.pycon.org/TX2007