On 2/14/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote
in response to [EMAIL PROTECTED]:
As far as I can tell, you still haven't even clearly expressed what your
needs are, let alone whether or not Twisted is suitable. In the reply
you're citing, you said that this sounded like something low
On 2/13/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Tristan is correct: this should be a patch against Twisted, or perhaps as a
separate library that could implement a reactor.
I think there is some confusion here.
I am not writing a competing event driven mechanism. What I was doing
was
* Richard Tew [EMAIL PROTECTED] [2007-02-14 16:49:03 +]:
I am not writing a competing event driven mechanism. What I was doing
was feeling out whether there was any interest in better support for
asynchronous calls.
I interpreted your suggestions as being about enhancing asyncore with
On 04:49 pm, [EMAIL PROTECTED] wrote:
On 2/13/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Tristan is correct: this should be a patch against Twisted, or perhaps as a
separate library that could implement a reactor.
I think there is some confusion here.
Quite.
I am not writing a competing
Jean-Paul Calderone wrote:
Greg, productive discussion is not furthered by the
unsupported statement of one position or another.
Sorry, I'll expand on that a bit. The problem I
was referring to is the turf wars between all the
event-driven frameworks that all want to do things
their own way.
[EMAIL PROTECTED] wrote:
sounded like
monkeypatching the socket and asyncore modules to provide asynchronous
file I/O based on the platform-specific IOCP API for Windows.
I don't think anyone's suggesting that any long-term
solution to all this would involve monkeypatching.
--
Greg
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
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.
On 2/13/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
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
On 12 Feb, 05:11 pm, [EMAIL PROTECTED] wrote:
On 2/12/07, Tristan Seligmann [EMAIL PROTECTED] wrote:
* Richard Tew [EMAIL PROTECTED] [2007-02-12 13:46:43 +]:
Perhaps there is a better way. And I of course have no concept of
how this might be done on other platforms.
Building on an
Martin v. Löwis wrote:
Greg Ewing schrieb:
the end result would be too
convoluted for ordinary people to understand and maintain.
That very much depends on what the end result would be.
True. What I should have said is that Guido *believes*
the outcome would be too convoluted. Christian's
At 08:41 PM 2/13/2007 +, [EMAIL PROTECTED] wrote:
and the microthreading features being discussed here are a trivial hack
somewhere in its mainloop machinery, not an entirely new subsystem that
it should be implemented in terms of.
It doesn't even require hacking the mainloop; it can be
Steve Holden wrote:
I know that there's work in progress (and indeed
almost complete) to put Stackless into 2.5
It might be less confusing to rename the current version of
Stackless to microthreads or something, since it's not
really stackless at all.
--
Greg
[EMAIL PROTECTED] wrote:
I have no problem with other, competing event-driven mechanisms being
developed;
The need for different event-driven mechanisms to compete
with each other is the very problem that needs to be
addressed.
If Twisted is designed so that it absolutely *has* to
use its own
On Wed, 14 Feb 2007 15:20:13 +1300, Greg Ewing [EMAIL PROTECTED] wrote:
Greg, productive discussion is not furthered by the
unsupported statement of one position or another.
Instead of only stating what you believe to be a problem,
explain why you believe it is a problem. A sentence like:
* Richard Tew [EMAIL PROTECTED] [2007-02-12 13:46:43 +]:
I currently use Windows. By using asyncore and monkeypatching in a
replacement socket module based on it [1] I can give users of Stackless
socket operations which invisibly block at the microthread level allowing
the scheduler to
On 2/12/07, Tristan Seligmann [EMAIL PROTECTED] wrote:
* Richard Tew [EMAIL PROTECTED] [2007-02-12 13:46:43 +]:
Perhaps there is a better way. And I of course have no concept of
how this might be done on other platforms.
Building on an existing framework that does this seems better
On 2/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Armin Rigo schrieb:
The history as I remember it is that Christian tried hard to integrate
the first versions of Stackless with CPython, but was turned town by
python-dev.
Are there public records of that? As I remember it, Christian
Richard Tew wrote:
See A Bit Of History
http://svn.python.org/view/stackless/trunk/Stackless/readme.txt
I admit that I haven't given Stackless more than a cursory look over,
but it seems to me that the real source of its complexity is because its
trying to add a fundamental architectural
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
Martin v. Löwis [EMAIL PROTECTED] wrote:
Richard Tew schrieb:
but at that stage I need to
poll two different resources for events. In order to avoid this it makes
sense to stop using asyncore for sockets and to write a new
replacement socket object based on IO completion ports.
I
Richard Tew wrote:
The ideal mechanism at the high level would be expanding asyncore into
a one-stop shop. Where all these things can be passed into it and
it can do the work to notify of events on the objects in a standard way.
+1. This sounds like an excellent idea. It's downright
silly
Talin wrote:
What I am getting at is that rather that doing heroic efforts to add
stackless-ness to the current Python code base without changing it,
instead define a migration path which allows Python to eventually
acquire the characteristics of a stackless implementation.
I think you've
On Tue, Feb 13, 2007 at 12:33:46PM +1300, Greg Ewing wrote:
Richard Tew wrote:
The ideal mechanism at the high level would be expanding asyncore into
a one-stop shop. Where all these things can be passed into it and
it can do the work to notify of events on the objects in a standard way.
Greg Ewing schrieb:
The other thing is that, even if some kind of migration
path could be found, Guido et al wouldn't want to follow
that path anyway -- because the end result would be too
convoluted for ordinary people to understand and maintain.
That very much depends on what the end result
On 2/10/07, Steve Holden [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
On Sun, Feb 11, 2007 at 03:35:29AM +0200, Yotam Rubin wrote:
Why don't you use Stackless? It's very simple, stable, and solves
quite completely the problems in writing concurrect code.
That's a great point -- I'm
Brett Cannon schrieb:
Of course Stackless isn't quite fully integrated with 2.5 (yet).
When did someone last suggest that Stackless become part of the core
CPython implementation, and why didn't that ever happen?
Don't remember the when. The why has always been that Christian's
hacks
On 2/11/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Brett Cannon schrieb:
Of course Stackless isn't quite fully integrated with 2.5 (yet).
When did someone last suggest that Stackless become part of the core
CPython implementation, and why didn't that ever happen?
Don't remember
Richard Tew schrieb:
If these generator coroutine microthreads went ahead and part
of it was improving the support for asynchronous calls in the
runtime and standard library, this would also be something
which also benefited Stackless Python. Even if they didn't go
ahead I would be
Hi Martin,
On Sun, Feb 11, 2007 at 07:09:29PM +0100, Martin v. L?wis wrote:
hacks into the core were complicated and he didn't even think
integration was worth it.
With emphasis on the latter. Christian never proposed (to my knowledge)
that Stackless should be integrated. Of course, he
Armin Rigo schrieb:
The history as I remember it is that Christian tried hard to integrate
the first versions of Stackless with CPython, but was turned town by
python-dev.
Are there public records of that? As I remember it, Christian never
actually submitted a patch for inclusion (at least not
Mostly for my own curiosity, I'm working on a PEP-342-based
microthreading library with a similar api to threads and threading
(coalesced into a single module). It uses coroutines and a trampoline
scheduler, and provides basic async wrappers for common IO operations.
It's not a
On 2/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Mostly for my own curiosity, I'm working on a PEP-342-based
microthreading library with a similar api to threads and threading
(coalesced into a single module). It uses coroutines and a trampoline
scheduler, and provides basic async
On Sat, Feb 10, 2007 at 03:00:28PM -0800, Brett Cannon wrote:
1. Write it
2. Get the community to use it and like it
3. Make it follow PEP 7/8 style guidelines
4. Write docs
5. Write tests
6. Promise to help maintain the code.
Thanks -- I hadn't really planned that far ahead yet. I expect
If this sounds like a terrible idea, let fly the n00b-seeking missiles.
Sounds like a good idea. We did this with ILU, and it helped manage
the overhead of threads quite a bit. Brett's comments on the next step
are right on target.
Bill
___
On Sat, Feb 10, 2007, Brett Cannon wrote:
On 2/10/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Is there any interest in including a simple microthreading module in
Python's standard library?
Basically, the list of things you need to do (typically, these are
just guidelines) are:
[EMAIL PROTECTED] wrote:
On Sun, Feb 11, 2007 at 03:35:29AM +0200, Yotam Rubin wrote:
Why don't you use Stackless? It's very simple, stable, and solves
quite completely the problems in writing concurrect code.
That's a great point -- I'm not necessarily producing this to solve a
problem I'm
37 matches
Mail list logo
