I wanted to make everybody aware that I've posted a (rather long and
involved) PEP proposal for adding micro-threading to Python on
python-ideas for feedback and review.
In a nutshell, this proposal implements the Twisted Deferred/Reactor at
the C level so that the Python programmer gets the advantages that Twisted
offers without having to write their code in an event driven style. Thus,
legacy Python code not written in the Twisted style (Django, TurboGears,
WSGI apps) will gain the benefits of Twisted with almost no additional
work.
This PEP provides similar benefits to GUI toolkits where, again, Python
programmers have been faced with event driven programming. So using this
PEP, GUI toolkits could hide this event driven programming from the Python
programmer, making GUI programming much easier. For example, you would no
longer have to use a modal dialog just to make the programming easier.
The C-level Deferreds and Reactor are not made visible to the Python
programmer (as they are in Twisted).
Rather, what is visible is a very simple micro-thread that allows for
"start_and_forg et" threads, "parallel" threads (where you're only
interested in the final return value) and fully cooperative threads
communicating over micro-pipes (which, BTW, gives us a new way to write
generators that allows one generator to simply call another one to have
the second generator's output included with its own output without having
to capture and pass back values).
As there is a great deal of traffic on comp.lang.pytho n, I don't expect to
be able to keep up with the posts here and would prefer to discuss this
on python-ideas...
If there is any interest in this, please let me know! If I don't see any
interest, I'll assume that it's not solving a real problem and will let it
quietly die on the vine...
Thank you for your attention!
-bruce
involved) PEP proposal for adding micro-threading to Python on
python-ideas for feedback and review.
In a nutshell, this proposal implements the Twisted Deferred/Reactor at
the C level so that the Python programmer gets the advantages that Twisted
offers without having to write their code in an event driven style. Thus,
legacy Python code not written in the Twisted style (Django, TurboGears,
WSGI apps) will gain the benefits of Twisted with almost no additional
work.
This PEP provides similar benefits to GUI toolkits where, again, Python
programmers have been faced with event driven programming. So using this
PEP, GUI toolkits could hide this event driven programming from the Python
programmer, making GUI programming much easier. For example, you would no
longer have to use a modal dialog just to make the programming easier.
The C-level Deferreds and Reactor are not made visible to the Python
programmer (as they are in Twisted).
Rather, what is visible is a very simple micro-thread that allows for
"start_and_forg et" threads, "parallel" threads (where you're only
interested in the final return value) and fully cooperative threads
communicating over micro-pipes (which, BTW, gives us a new way to write
generators that allows one generator to simply call another one to have
the second generator's output included with its own output without having
to capture and pass back values).
As there is a great deal of traffic on comp.lang.pytho n, I don't expect to
be able to keep up with the posts here and would prefer to discuss this
on python-ideas...
If there is any interest in this, please let me know! If I don't see any
interest, I'll assume that it's not solving a real problem and will let it
quietly die on the vine...
Thank you for your attention!
-bruce
Comment