A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-June/045171.html below:

[Python-Dev] Re: Re: Stackless Python

[Python-Dev] Re: Re: Stackless PythonTerry Reedy tjreedy at udel.edu
Wed Jun 2 18:24:43 EDT 2004
"Gordon McMillan" <gmcm at hypernet.com> wrote in message
news:200406021422.42480.gmcm at hypernet.com...
> Let me pop my head up for a second.

Welcome ;-)

> You won't see Stackless do anything (from a user's perspective) that
can't be
> done without Stackless[1].
> [1] Though perhaps you can do more / quicker, because of more efficient
> memory usage than an implementation using threads.

Except that for real-time game simulations, running smoothly without
freeze-ups (and crashes) *is* experientially different, for the gamer-user,
from being frozen in the middle of deadly battle, which is typically when
freeze-ups occur.

> Stackless (like generators) just makes some things much easier.
> Basically, any state machine(s) with complex internal state (and
relatively
> simple events) will be much more straightforward to write in Stackless.

Enought more so to lead to less bugs and/or more features (if the same time
is allotted)?

> I can't speak to the new Stackless, but in 2000 I did a proprietary,
> commercial app for Avid that used Stackless (and lots of C extensions).
It
> went through Avid's QA, so it would not have been released if it crashed.

OK, another success story, even if somewhat old.

Terry J. Reedy




More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4