Given the rush of interesting discussions and progress which occurs in the
two weeks before Python conferences, I propose that we have a bi-weekly
conference. We'll just have to remember to cancel them at the last minute
except a couple of times a year.
Stackless Python 1.0
A Python Implementation That
Does Not Use The C Stack
* plus the real toy *
Continuation Module 0.6
Continuations as First Class Objects
What is it?
A plugin-replacement for core Python.
It should run any program which runs under Python 1.5.2 .
But it does not need space on the C stack.
Why did I write it?
Stackless Python was never written before (afaik), since it
was said to be impossible without major rewrites of core Python.
I have proven the controverse: It is easy to write, just hard to think.
About 3 times harder was finally the continuation module.
The whole project took about 6 man months where 80 percent of
the time was thinking and trying. The rest was coding and to
become a reference counting champion :-)
Version 1.0 has been optimized like hell and is now
3-5 percent faster than Standard Python.
Continuation module is in version 0.6, very stable,
and it allows to save a program's "future" at any
time, in a portable way. Continuations are callable
Python objects with a very small footprint.
Who needs it?
Since the continuations are done, this is no more
only useful for C programmers who want to try certain new
ideas. Everybody who is interested to develop his
own generators, coroutines and tiny threads is
invited to check it out.
Status of the final 1.0:
Pystone works correctly and is 5% faster than standard
Python. Version 0.3 was 10 percent slower.
Continuations work with PythonWin and Idle.
The overall result is now better than expected,
and I'm happy to call this *FINAL*
(until the next version of course:)
Downloadable files can be found at
Some older documentation:
Some better documentation can be found in my IPC8 paper:
or be read directly as HTML
Source code and a VC++6.0 build for Windows (340K):
cheers - chris
Christian Tismer :^) <mailto:email@example.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.python.net
10553 Berlin : PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF
we're tired of banana software - shipped green, ripens at home
Stackless Python 1.0</A>
- a version of Python 1.5.2 that does not need space on the C
I have a question/suggestion about ''.join in Python 1.6.
Suppose I have this list:
l = ["This", "is", "a", "test"]
Currently, I would join it this way into a tab-delimeted string:
s = string.join(l, '\t')
In 1.6, I should do it this way:
I think it would be better to have that method on the *list*:
That's more clear, isn't it?
Please correct any bad English you encounter in my email message!
-----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com
GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE?
Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y
-----END GEEK CODE BLOCK-----
I was just looking through the Tools dir of the CVS version
(looking for a tool which autoexpands tabs in Python source
files -- which I didn't find) and found some other useful scripts
along the way.
To my surprise these executable files did not have a .py
extension even though were Python source files. Is this
intended ? I find that scripts like "world" provide useful
information which would be nice to have in the standard
lib -- with .py extension...
I noted that at least in my CVS tree the Tools/ht2html
dir does not include any executable: have I missed something ?
The script Tools/scripts/parseentities.py is not executable
for some reason.
Python Pages: http://www.lemburg.com/python/
I am championing a Developers' Day session on a Python compiler.
There is a short Web page describing the goals of the session at
I'd appreciate feedback on the content and format of the session. If
you have ideas for what we should talk about or do, please followup to
me or to the list.
Happy New Year!
I've attached a new imputil.py to this message. It isn't posted on my page
yet, as I'd like some feedback before declaring this new version viable.
In this imputil, there is an ImportManager class. It gets installed as the
import hook, with the presumption that it is the only import hook
(technically, it could chain, but I've disabled that for now). I think
Python 1.6 should drop the __import__ builtin and move to something like
sys.import_hook (to allow examination and change). Another alternative
would be sys.get_import_hook() and sys.set_import_hook().
[ I don't think we would want a "set" that returned the old version as the
only way to get the current hook function; we want to be able to easily
find the ImportManager instance. ]
The ImportManager knows how to scan sys.path when it needs to find a
top-level module/package (e.g. given a.b.c, the "a" is the top-level; b.c
falls "below" that). sys.path can contain strings which specify a
filesystem directory, or it can contain Importer instances.
The manager also records an ordered list of suffix/importer pairs. The
add_suffix() method is used to append new suffixes, but clients can also
access the .suffixes attribute for fine-grained manipulation/ordering.
There is a new importer called _FilesystemImporter which understands how
to look into a directory for Python modules. It borrows/refers to the
ImportManager's .suffixes attribute, using that to find modules in a
directory. This is also the Importer that gets associated with each
The importers used for suffix-based importing are derived from
SuffixImporter. While a function could be used here, future changes will
be easier if we presume class instances.
The new imputil works fine (use _test_revamp() to switch to the new import
mechanism). Importer subclasses using the old imputil should continue to
work, although I am deprecating the 2-tuple return value for get_code().
get_code() should return None or the 3-tuple form now.
I think I still have a bit more work to do, to enable something like
"import a.b.c" where a.zip is an archive on the path and "b.c" resides in
the archive. Note: it *is* possible to do
sys.path.append(ZipImporter(filename)) and have "a.b.c" in the Zip file.
It would simply be nicer to be able to drop arbitrary .zip files onto the
path and use their basename as the top-level name of a package. Anyhow: I
haven't looked at this scenario yet to find what the new system is missing
As always: feedback is more than appreciated! Especially from people using
imputil today. Did I break anything? Does the new scheme still feel right
to you? etc.
p.s. I'd also like to remove PackageArchiveImporter and PackageArchive.
They don't seem to add any real value. I might move DirectoryImporter
and PathImporter to an "examples" file, too.
Greg Stein, http://www.lyra.org/
It just occurred to me as I was replying to a request on the main list, that
Python's text handling capabilities could be a bit better than they are.
This will probably not come as a revelation to many of you, but I finally
put it together with the standard argument against beefing things up
One fix would be to add regular expressions to the language core and
have special syntax for them, as Perl has done. However, I don't like
this solution because Python is a general-purpose language, and regular
expressions are used for the single application domain of text
processing. For other application domains, regular expressions may be of
no interest, and you might want to remove them to save memory and code
and the observation that Python does support some builtin objects and syntax
that are fairly specific to some much more restricted application domains
than text processing.
I stole the above quote from Andrew Kuchling's Python Warts page, which I
also happened to read earlier today.
What AMK says makes perfect sense until you examine some of the other things
that are in the language, like the Ellipsis object and complex numbers. If
I recall correctly both were added as a result of the NumPy package
I have nothing against ellipses or complex numbers. They are fine first
class objects that should remain in the language. But I have never used
either one in my day-to-day work. On the other hand, I read files and
manipulate them with regular expressions all the time. I rather suspect
that more people use Python for some sort of text processing than any other
single application domain. Python should be good at it.
While I don't want to turn Python into Perl, I would like to see it do a
better job of what most people probably use the language for. Here is a
very short list of things I think need attention:
1. When using something like the simple file i/o idiom
for line in f.readlines():
the programmer should not have to care how big the file is. It
should just work in a reasonably efficient manner without gobbling up
all of memory. I realize this may require some change to the syntax
of the common idiom.
2. The re module needs to be sped up, if not to catch up with Perl, then
to catch up with the deprecated regex module. Depending how far
people want to go with things, adding some language syntax to support
regular expressions might be in order. I don't see that as
compelling as adding complex numbers however. Another possibility,
now that Barry Warsaw has opened the floodgates, is to add regular
expression methods to strings.
3. I've not yet used it, but I am told the pattern matching in
Marc-Andre Lemburg's mxTextTools
(http://starship.python.net/crew/lemburg/) is both powerful and
efficient (though it certainly appears complex). Perhaps it deserves
consideration for incorporation into the core Python distribution.
I'm sure other people will come up with other suggestions.
Skip Montanaro | http://www.mojam.com/
skip(a)mojam.com | http://www.musi-cal.com/
847-971-7098 | Python: Programming the way Guido indented...
Hi, folks. I'm putting together guidelines for submissions to the
Software Carpentry design competition (www.software-carpentry.com), and
would like to know what I should recommend as a Python GUI toolkit. As I
understand it, the alternatives are:
- Tkinter: the "standard" answer, but many people think it's showing its
age, and it's an installation and update headaches because of its Tcl
- some other GUI toolkit: but there's no consensus on which one, and
documentation is lacking.
- CGI scripts (i.e. all interfaces are web pages): has the virtue of
simplicity, but could also make some useful interfaces difficult to
build (e.g. no drag and drop), and would require users to run a server,
or at least get exec privileges, which can be an installation headache.
If I've missed a good answer, or if there's somewhere else I should look
for a solution, I'd be grateful for a pointer.