Hi all, and those explicitly addressed,
first of all, I'm happy that my talk worked quite ok, and that Guido
reacted very positively on the idea of making it pip-installable,
including virtualenv.
Of course we are cheating quite a bit, because stackless is not
really a package, but suffers that little wart of "being an executable
after all".
And today, I heard the talk of Mark Shannon which was just great.
I'm sitting in the shadow at the conference, let the impressions
flow, and try to get something sorted out.
On Stackless PyPy:
----------------
Yes, special care must be taken to at least pretend that we have simple
packages, although we don't.
For instance, as you said, having PyPy installed and then with a configured
dependency of stackless-python, something like this will probable happen
right now (but I'm not sure how much checking stackless does right now?)
I guess, pypy running "pip install stackless-python" should right now reject
installation, since there is no stackless binary built for PyPy.
I would imagine that, if done right, pypy running "pip install
stackless-python"
should figure out that on PyPy, this only means to at most ensure that
the PyPy
installation is able to "import stackless". If that works, then PyPy was
built with
stackless support. Right now this is in some broken/unready state, but
will be
working, pretty soon.
On HotPy and Stackless
---------------------
As far as I understood Mark Shannon today, in some private chat during
lunch, HotPy
does some changes to the obvious modules, like ceval.c (heavily),
typeobject.c
and probably other kernel-related stuff (traceback, pystate etc.).
I will need a closer look how these changes are made, and how feasible it is
to add a stackless version. I would like to implant the idea right now
and early
enough. Right now I'm even wondering if HotPy is maybe better suited to
implement stackless features than CPython itself, because HotPy does in the
first place, what Stackless achieves painfully via crazy tricks: Make
CPython tail-recursive.
So I have the gut feeling that Stackless-Hotpy could become a new and
possibly simpler
branch, because all the hairy changes that are needed are already in HotPy.
But this still is Vodoo.
In any case, I would like to encourage everybody to look into HotPy and what
we can do for it to thrive! It is a really nice improvement to CPython
and can become
a valid alternative for people who cannot use PyPy right now.
HotPy needs support, committers, repository, community, all of that. And
note
that Guido is interested in it.
I'm interested to contribute. Of course, I want it to have a stackless
option in every
Python flavor.
General thoughts on PIP and the future:
----------------------------------
I think the PIP approach to simplify stackless is very valid, although
it has
its subleties, like "not scaling well". This can be improved and better
supported
later. I think it is important, and to do it right now, to state a fact.
We then get into
a better position, not asking for something to be included somewhere, but to
show that we have a pip installer, which puts us into a better position.
This kind of installation does not scale well, because if somebody does a
"pip install HotPy" after "pip install stackless-python", (s)he will
loose stackless.
A better installer would need to know about these combinations and to draw
the appropriate decision when detecting an existing stackless. It would need
to download/unpack/build a stackless-enabled HotPy version (and the
right one),
instead of failing.
I think that could also have some impact on how easy_install and distribute
are developed further, since today this would not work at all.
In any case, there _are_ certain projects that need a common way to
collaborate
and give the user a hassle-free experience, as if they just were simple
packages. We need to support the useful and valid combination of that and
pretend composability to some extent.
I think by doing so, we can avoid what happened to Stackless for so many
years:
A niche-existence, where people were reluctant to try it.
So in some sense, my idea is to start some "umbrella" project, that
gives smaller
projects that need to change the interpreter binary a better position.
There is
no longer every other single project in some concurrence with CPython.
I guess nobody ever wanted that. By doing a combined effort, we instead
would gain a positive, collaborative attitude:
We all love CPython, and you get your choices to select what you are
specially interested in. That is where I want to go.
Right now the choices seem to be
HotPy
Stackless
PyPy (maybe, to some extent)
but I'm open do discuss what else could go into this list.
Umbrella-Project
============
Question:
---------
Should we come up with an umbrella project on BitBucket, for instance
"alternative-python" or "special-python"
which then has
- an installer project
- HotPy
- stackless
- pypy (concerning setup issues)
- (more proposals?)
as repositories?
Then this project would have its own mailing list and issue tracker, and
a couple
of submitters.
I would certainly like to be in this, as I'm interested in every aspect
of Python
and how to support improvements in any direction.
Q: would Jython fit into this picture as well?
Please let me know your thoughts.
I'm sitting at EuroPython, Florence including Friday and maybe Sat. evening.
Contact me by email or find me at the conference.
Let's talk!
Cheers -- Chris
On 7/5/12 12:29 AM, Hervé Coatanhay wrote:
Hi all,
I was wondering. Now that `stackless-python` is like any other pypi
package on a pip perspective, what will/should happen if I want to use
a package that has `stackless-python` as a dependency in a pypy
virtualenv ?
cheers,
Hervé
On Thu, Jun 28, 2012 at 8:42 PM, Christian Tismer
<[email protected] <mailto:[email protected]>> wrote:
Hi Stefan,
On 6/28/12 5:37 PM, Stefan Drees wrote:
Hi Chris,
Am 28.06.12 16:51, Christian Tismer wrote (slightly edited):
...
Stackless becomes a PyPI package that contains only the
binary and the
few changed library modules.
After
pip install stackless-python
you have stackless inside site-packages, and you get a
message that
tells you
"Along-side with pythonX.Y, you now have a command
slpythonX.Y which you can run as an alternative"
and you can also
pip uninstall stackless-python
> ...
to me this sounds good enough for easing the people into
wanting to try stackless out.
Maybe a different name for the modified python eg. matching
the package name from the install command stackless-python,
stackless-python2.7 etc?
Possible. The name "stackless-python" was proposed in a parallel
discussion on the virtualenv list. Maybe it is better to use a shorter
name since I assume some laziness if people need this package
at all ;-)
But there are many packages with a name different from what gets
installed - for instance distribute, which is cheating, it just
replaces
the easy-install package with a different version.
I share the view, that a virtualenv is and should allways be
an additional option, transparent for the package.
Yes. I thought things would be easier abusing virtualenv, but that
seems to be not true.
So I ended up with a "piggy-back stackless".
Btw., I am still playing with wild ideas, like on "import stackless"
replacing and restarting the interpreter completely...or some
other tricks
that emulate an extension.
But it is not trivial without a mechanism to intercept the normal
startup-code of cpython.
Mayme I'll keep it simple and get somewhere at all ;-)
cheers -- chris
--
Christian Tismer :^) <mailto:[email protected]
<mailto:[email protected]>>
tismerysoft GmbH : Have a break! Take a ride on
Python's
Karl-Liebknecht-Str. 121 : *Starship*
http://starship.python.net/
14482 Potsdam : PGP key -> http://pgp.uni-mainz.de
work +49 173 24 18 776 <tel:%2B49%20173%2024%2018%20776> mobile
+49 173 24 18 776 <tel:%2B49%20173%2024%2018%20776> fax n.a.
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3
BF04
whom do you want to sponsor today? http://www.stackless.com/
_______________________________________________
Stackless mailing list
[email protected] <mailto:[email protected]>
http://www.stackless.com/mailman/listinfo/stackless
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
--
Christian Tismer :^) <mailto:[email protected]>
tismerysoft GmbH : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/
14482 Potsdam : PGP key -> http://pgp.uni-mainz.de
work +49 173 24 18 776 mobile +49 173 24 18 776 fax n.a.
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
_______________________________________________
Stackless mailing list
[email protected]
http://www.stackless.com/mailman/listinfo/stackless
