[Stackless] Google Summer of Code - PSF / Time is Short

Richard Tew richard.m.tew at gmail.com
Wed Mar 21 14:58:06 CET 2007

On 3/21/07, Carlos Eduardo de Paula <carlosedp at gmail.com> wrote:
> I have one issue though, some questions proposed by monkeypatch can be
> addressed by other ways... like the twisted approach in the networking
> side, where we can a nonblocking network access have using the last
> example of the blockOn function posted some days ago.

Ah.  Twisted.  There are two problems with this.  The first is that I do
not have the chops to mentor any summer of code project which
involves Twisted.  The second is that a primary goal in writing the
stacklesssocket module and the existing monkeypatching prototype
was that there be no dependencies, and that they just use what is
available in the standard library.

Now I don't want to complicate things for you application wise, so
I will try and cover all my bases with this email in order to avoid
sowing confusion.

That I cannot mentor a Stackless related project involving Twisted
has two possible solutions.  The first is if Christian could mentor it
and the second if that fails, is getting someone who knows Twisted
to co-mentor it (assuming that is allowed).  But I am not sure how
workable the second would be.

The dependencies thing isn't set in stone.  But one of the things
originally discussed when this was brought up on the mailing list
initially, was that we might consider incorporating the monkeypatching
solution as part of the Stackless distribution which could be optionally
enabled.  If monkeypatching has no dependencies, then this can just
be done.  But if it has dependencies, then it won't be done or it will
be done but it will have to error with something like "You need to install
Twisted before you can enable this".

And then Twisted becomes a dependency for Stackless itself, which
I am not too keen on, even if it is an optional one.  I have read on
numerous occasions how the fact that Stackless is a fork of Python
causes people to shy away from it.  What I see when there are
dependencies complicating the process are even more people shying
away.  I would probably prefer that the it not be included in the
Stackless distribution if this were the case.

Then there is a general concern about whether Twisted gets in the
way of the monkeypatched things just being used "as is".  One thing
which has made the stacklesssocket module so easily usable by
people is that they can just download it and use it directly in place
of the socket module in exactly the same manner as they would
have normally used sockets.  Given my own non-use of Twisted and
the level of confusion that went on, on the list, in terms of how to
get Stackless and Twisted to best work together, how the use of
Twisted will affect people wanting to use the monkeypatched
facilities in the same manner.. well, I don't know the repercusions

But if you are only going to implement the posix side of
the monkeypatching, then it wouldn't be suitable for inclusion
anyway until it had matching Windows support at some
later stage by someone who might flesh it out in that direction.

> The file access module would be a great addition, but i need to study
> ctypes and posix file access more deeply...

If you were going the Twisted direction for your monkeypatching solution
it might be able to do asynchronous IO for you already in a cross
platform way.  I know it has a implementation of Windows asynchronous
file IO support, although if I recall correctly it is unfinished.

> The documentation is a much needed feature, and I was already thinking
> about it.. maybe write something like Grant Olson's tutorial with many
> usage examples.

I was thinking that the API documentation at least, would be like the
documentation for modules in the standard Python distribution.  But that's
just a thought.

In any case, I hope this doesn't confuse things for you.


Stackless mailing list
Stackless at stackless.com

More information about the Stackless mailing list