For the edited interviews, please see:
Interviews with Creators of Vyper and Stackless Python
and
Interviews with Developers of JPython and Python for .NET
Note: Questions from Mertz are highlighted in blue, and answers from the various interviewees in red.
> Q. Stackless Python has been absolutely fascinating to read about for > me. Like most earthbound programmers, I have trouble getting my mind > wholly around it, but that is part of what makes it so interesting to > me. Well, I'm earthbound, too, and you might imagine how difficult it was to implement such a thing, without any idea what a continuation is and how it should look like in Python. Getting myself into doing something that I wasn't able to think was my big challenge. After it's done, it is easy to think, also to redesign. But of those six months of fulltime work, I guess five were spent goggling into my screen and banging my head onto the keyboard. > There is a joke about American Engineers and French Engineers. The > American team brings a prototype to the French team. The French team's > response is "Well, It works fine in practice; but how will it hold up in > theory?" I think the joke is probably meant to poke fun at a "French" > style, but to my own mind I completely identify with the "French" > reaction. Bracketing any specific national stereotypes in the joke, it > is my identification in it that draws me to Stackless. CPython works in > practice, but Stackless works in theory! (In other words, the abstract > purity of continuations is more interesting to me personally than is the > context switch speedups of microthreads, for example). I see. My feeling is a bit similar. After realizing that CPython can be implemented without the C stack involved, I was sure that it *must* be implemented this way; everything else looks insane to me. CPython already pays for the overhead of frame objects, but it throws all their freedom away by tying them to the C stack. I felt I had to liberate Python. :-) > For readers though, let me ask the basics: > > Q. Exactly what is Stackless Python? Is there something a beginner > can get her mind around that explains what is different about Stackless? Stackless Python is exactly a Python implementation that does not save state on the C stack. It does of course have stacks, as many as you want, but these are Python stacks. The C stack cannot be modified in a clean way from a language like C, unless you do it in the foreseen order. It imposes a big promise on you: You will come back, exactly here, exactly in the reverse way as you went off. "Normal" programmers do not see this as a restriction in the first place. This is so since they have to learn to push their minds onto stacks from the outset. There is nothing bad about stacks, and usually their imposed execution order is the way to go, but that does not mean that we have to wait for one such stack sequence to complete, before we can run a different one. Programmers realize that when they have to do non-blocking calls and callbacks. Suddenly the stack is in a way, we must use threads, or explicitly store state in objects, build explicit, switchable stacks, and so on. Consumer/producer problems lead to unnatural formulations of algorithms, just because the one must call the other, and there is no natural order for this, but it is an artifact. See for instance todays XML parsers. They provide hooks for the programmer to insert his own behavior on certain events. But this is no natural thinking, it is reactive programming. The aim of Stackless is to deliver the programmer from these problems. When we wrote our first simple Pascal programs, these were easy ones. A couple of loops, cases, some input and output. This is like beginners think of programming, and I want them to be allowed to keep with this simple style. With Stackless Python, you can write both the consumer and the producer as if they were a simple little Pascal main program. > Q. Understanding Stackless involves thinking about some concepts that > are novel for a lot of workaday programmers. Is it possible to give the > sound bite expanation of the C-stack? Of continuations? Of coroutines? > Of microthreads? Of generators? (I think it was Tim Peters who > characterized continuations as (roughly) "The control structure the > fundamentally underlies all others, and is more basic than the GOTO" -- > is that about right?) Please let me defer this one. Remind me to answer it, please. > Q. Why did you start this project? Was it just an itch you had to > scratch (as is often said of opensource projects)? Or is there a more > practical motive behind it? What is most important to you, the > theoretical issues underlying what you have done, or the specific > performance improvements that are likely to be enabled (for example, > with microthreads)? It was in May 1999. Sam Rushing was playing with a hardware coroutine implementation, and a dicussion of python-dev begun. Such a stack copying hack would never make it into Python, that was clear. But a portable, clean implementation of coroutines would, possibly. Unfortunately, this is impossible. Steve Majewski gave up five yoears ago, after he realized that he could not solve this problem without completely rewriting Python. That was the challenge. I had to find out. Either it is possible, and I would implement it. Or it is not, and I would prove the impossibility. Not much later, after first thoughts and attempts, Sam told me about call/cc and how powerful it was. At this time, I had no idea in what way they could be more powerful than coroutines, but I believed him and implemented them. Six or seven times, always a complete rewrite, after I understood more. Yes, finally I wanted to create threads at blinding speed, but my primary intent was to find out how far I can reach at all. > Q. On the practical side, just what performance improvements is > Stackless likely to have? How great are these improvements in the > current implementation? How much more is possible with tweaking? What > specific sorts of applications are most likely to benefit from > Stackless? With the current implementation, there is no real advantage for Stackless over the traditional calling scheme. Normal Python starts a recursion to a new interpreter. Stackless unwinds up to a dispatcher and starts an interpreter from there. This is nearly the same. Real improvements are there for implementations of coroutines and threads. They need to be simulated by classes, or to be real threads in Standard Python, while they can be implemented much more directly with Stackless. On the other hand, there is a 12 percent speed improvement (pystone) which stabilizes at, say, 8 percent for Stackless in the current implementation. This has nothing to do with Stackless, but comes from a rigorous optimization and redesign of the main interpreter loop. These optimizations could be done without Stackless at all, but my license forbids exactly that. Much more improvement of the core doesn't seem very possible without dramatic changes to the opcode set. But a reimplementation with more built-in support for continuations et al. can improve the speed of these quite a lot. Specific applications which might benefit quite much are possibly like Swarm simulations, or multi-user games with very many actors, performing tiny tasks. One example is the EVE game which is under development, using Stackless Python. http://www.eve-online.com, see section 8.6 of the FAQ: http://www.eve-online.com/faq/faq_08.asp > Q. There has been a lot of discussion on the Python newsgroup about > incorporating your Stackless patches into the main Python source. I > have a number of questions related to this: > > - How likely to you think such incorporation is? If it is moderately > likely, what version number will Python be at when Stackless makes it > into the trunk? I consider it moderately likely, very much dependent on how easy I can implement it again in an easy to understand manner, and depending on the mood of the BDFL. My current target is Python 2.1 . > - There are a few arguments against incorporating Stackless into the > CPython trunk, what do you think of them? > > It has been claimed that it is impossible to be Stackless in JPython, > and in the interest of keeping the versions in sync, Stackless should > not be in the main CPython. True? False? True but irrelevant? True, but a very bad argument. Like forbidding a book for the fact that it cannot be translated into every language. The problem is: In order to be stackless, you need to build something like a stackless core engine. CPython has a core engine, which I could changed to be (nearly) stackless. JPython does not have an engine at all, since it translates into Java VM code, which must be treated like hardware in this case. But the real drawback is: "Normal" hardware would allow to implement a stackless core. Java's VM does not, without changes. The alternatives are: Change the VM, or change JPython to implement a stackless core. The latter would be way too slow... Vice versa: If CPython would translate directly into C code instead of using its frames, we would be in the same Dilemma as Java is, since C doesn't support continuations, which means switching stacks. Assembly language would of course allow it, if it were allowed at all :-) . There has been a lot of work on C-- by Simon Peyton Jones et al., a portable assembler. This might be a chance when used as a frontend for code emission. I'm still not absolutely shure if the java way is impossible. Some more investigation is necessary, given that I don't output valid Java source, but VM instructions. This thought is very joung (came up while writing this). > It has been claimed that since Stackless represents a change in > thinking, Python maintainers would not be able to work with a > Stackless-patched trunk (maybe including Guido). Is this true? Is > it important? I think the Stackless part of the implementation is not that hard as people want to claim all the time. They simply don't read it since they believe it must be hard. They basically have to understand the one very basic principle: Try to change every recursion into tail-recursion, then avoid the recursive call and defer it to the calling dispatcher. This is everything and all. Making the implementation easier to understand is another thing, but this little principle is somethingthat I can demand from every true core developer. > - What do YOU think about incorporating Stackless into the CPython > trunk? It might help with your own leisure time, but how important > should it be to other Python users? For that matter, how important > is such an incorporation to you? Is Stackless just as good as an > available branch, or does something get better if it becomes the > version? Well, there are arguments for and against it. Against: As long as I'm sitting on the Stackless implementation, it is mine, and I do not need to discuss the hows and whys. But at the same time, I'm struggling (and don't manage) keeping up with CVS. Better to have other people doing this. For other Python users, who aren't necessarily interested in kinky stuff, there are a few: They won't recognize Stackless at all, jzst for the fact that it happens to be faster, and that the maximum recursion level now is an option and no hardware limit. And there is another promise for every user: There will be pickleable execution states. That means you can save your program while it is running, send it to a freind and continue running it. And, as long as there is just the stackless core, there is no real incompatibility to JPython than the possibility to extend it. Coroutines, Generators, uThreads and continuations will be only available through extension modules. The core is just prepared to stand and support all of this. Finally, I'm all for it, provided that all my stuff makes it into the core, at some time. I do not want to see a half-baked solution, as has ben proposed several times. > Q. The goal of Stackless is to be 100% binary compatible with CPython. > Is this goal entirely accomplished, or are there subtle "gotcha" > remaining? Even in obscure areas, are there thing programmers need to > watch out for in porting between Stackless and CPython (or to JPython, > Python.NET or Vyper, inasmuch as you know about these other > implementations)? Stackless is 100% binary compatible at the moment. That means: You install Python 1.5.2, you replace pythpon15.dll with mine, and everything still works, also every extrension module. It is not a goal, it was a demand, since I didn't want to tak care about all the extensions. Stackless was always develped under pythonWin, and PythonWin with all of its modules was never compiled against Stackless. If I'm going to rework it for inclusion into the core, this is no longer an issue, since everything will have to be recompiled then anyway (and fortunately not by me:). No idea what I should say about the C/J/.NT/Vyper part? > Q. Are there other aspects of Stackless that I have not asked about, > that you think "Charming Python" readers should know about? I need to defer this as well, no idea at the moment. Well, there is something. Onemajor difficulty at the moment is that Stackless isn't really as stackless as I'd like it to be. There are still places where recursions are possible. BTW they are always allowed. It was quite a difficult task to handle this properly, but it has been completely solved. Recursions still exist in all non-standard calls, like all the predefined __xxx__ methods, imports and a few more. Frames which span a recursion have the same restrictions as before. Especially, they are unable to split off a continuation, since they are in a non-determinate state. This is painful in some cases. For instance, pickling of frame chains is easy, as long as no such locked frame is involved. Pickling of locked (recursion) frames isn't possible without very hairy tricks. Furtunately, this works with uThreads, see below. > Q. Any thoughts on future directions for Stackless? Anything new and > different expected down the pipeline? Quite likely are: A patch set of the current implementation for Python 1.6 comes first. Gordon Mc Millan is writing a PEP for including Stackless, and this will trigger a re-implementation with more substantial core changes for Pyhton 2.1, binary incompatible to some (few) extensions, easier to understand and to maintain. Pickling support will be partially implemented. This will be working most likely for uThreads first, since they provide the cleanest abstraction at the moment. They are living in such a "clean room" that the remaining recursion problem doesn't exist. My final goal is to remove *all* interpreter recursion from Python. This is very hard,since it needs to change quite much, add new opcodes, unroll certain internal calling sequences and so on. I will take this on after the current level of Stackless is incorporated, not before.
>Q. Exactly what is JPython? > >Q. What were the reasons for developing JPython in the first place? >What was wrong with the original CPython that required another version? > >Q. What strengths or advantages does JPython have over CPython? JPython gives supreme access to its underlaying implementation language. In most (properly all) C-based script languages, a C function must be wrapped in a thin layer of code that serves to expose the C function to the script language. Fine tools like SWIG exists to automate the creation of this wrapper code. JPython requires no such wrapper. All java code ever written is directly available for use from JPython. The integration goes both ways. Classes and instances defined in JPython can be passed to java code as if they were ordinary java classes and instances (which is exactly what they are). The embedding/extending API is very close to the way it is exposed to python. It makes access to JPython objects from within an application or module quite elegant. This beaty comes in part from the fact that JPython and java are both OO languages. Jim took great advantage of this. >What weakness or disadvantages does it have? JPython only gives access to java code. Not to any of the existing C modules. So every python module implemented in C must be re-implented in java. And CPython have quite a lot modules. There are almost no documentation to the embedding/extending API other than the source. >Q. Since JPython combines Java and Python, in a certain sense, what >strength and advantages does JPython have over Java? Likewise, weakness >and disadvantages? > >Q. How widely used do you think JPython is? Are there particular >industries or types of problems that are a particularly good match for >JPython? > >Q. Two technical matters surrounding JPython have particularly struck me >in discussions on the Python newsgroup. I was hoping you might weigh in >on either of these: > > (1) There is a lot of talk about the fact that JPython uses true > garbage-collection, while CPython uses reference counts. Do you > believe this is an advantage of JPython, or simply an implementation > requirement of Java? GC is necessity of java, but when porting C-based modules to java, I have enjoyed that I could ignore all the INCR/DECR of references. > Do you think CPython 2 (or Python 3000) should > go in the JPython direction? Reference-counting works quite nicely for CPython. There should not be any reason to change that in any fundamental way. GC works nicely for java and JPython. The few incompatibilities these differences have caused to real python applications can easily be avoided by a little careful extra coding. > (2) Christian Tismer's Stackless Python seems to have generated a lot > of excitement among Python users; many have argued that his patches > ought to be integrated into core CPython. One argument raised against > this change in CPython is that it is not possible to fold the same > changes into JPython, and keeping the versions in accord is important. > Do you think the technical appraisal of incompatibility between > JPython and Stackless Python is accurate? Yes and no. Well, I'm out on limb here because I do not fully understand Tismer's changes. If we look at only pure python code (without any java involvement) it should be possible to design a interpreter like ceval() that doesn't recurse. It would take a major redesign of the way JPython currently work and would properly loose the excellent speed JPython have by compiling into java byte code. But I think it is possible. However, I think the JPython argument against stackless is just one of many. > If so, how important do you > think keeping JPython and CPython compatible at this level is? Actually adding the stackless patches to CPython would not create much incompatibility, I think. The problem and most of the controversies occurs over the "continuation" module. I wouldn't be bothered much if stackless was added to CPython. If the "continuation" module was added as core, I fear I would encounter programs that I cannot read and understand. (It is generally accepted that continuations require a "brain upgrade" in order to understand them). > Underlying this question is whether JPython is an attempt to keep up > with CPython, The fact is that JPython *is* trying to catch up. Almost all new features are added to CPython first. (Well, JPython did have string method before CPython did). JPython have a disadvantage here because CPython have 30 times as many core developers as JPython does. But even so, a JPython version exists with almost all the new features in CPython1.6. > or whether the two are co-equal implementations: They are equal. But in the real world one is a little more equal that the other. >Q. What, if any, significant incompatibilities exist between JPython and >CPython? Modules that have/can not be implemented in JPython. Some modules can only be implemented as JNI modules and as such may not be useful in the deployment environment. >How easy am I likely to find moving application code between >the two implementations? There have been (and still are I'm sure) many small differences in the exact way the implementations works. >What are the major gotchas? Tellingly enough, the problems I encountered when porting my own script and programs as well is IDLE, PySol and the PMW toolkit was *not* the random reclaiming of the garbage collection or the missing __del__ method. It was just the minor stuff that no other had encounter before. - mutability of the __name__ attribute. - changing __class__ caused a call to the __setattr__ hook. - Assigning to sys.modules['foo'] during the import of "foo" module.
Q. Exactly what is JPython? My standard marketing-speak reads: "JPython is a 100% Pure Java implementation of the Python programming language. It allows users to compile Python source code to Java byte codes, and run the resulting bytecodes on any Java Virtual Machine. It is a very seamless and smooth integration with Java: from Python you have complete access to all Java libraries, can build applets, can integrate with Java beans, and can subclass Java classes in Python and vice versa. Like Python, and unlike Java, JPython can also be used interactively: just type some JPython code at the prompt and see the results immediately." In simple terms, it allows the Java programmer to script any Java code she wants. This translates to a 2-10 times fewer lines of code in JPython than in Java. Because Python is a dynamically typed language, you can develop applications much faster, with many fewer bugs, and end up with a much more flexible program. Q. What were the reasons for developing JPython in the first place? What was wrong with the original CPython that required another version? I should point out here that JPython was invented by Jim Hugunin, who is now working for Xerox PARC's Aspect Oriented Programming project. Knowing Jim, I think his primary reason for creating JPython was the pure challenge. At the time, many people in the Python world just didn't think it could be done; Guido himself was one of the skeptics. Jim proved them wrong! So why continue to develop JPython now that the challenge has been met? Because it's the most valuable Java tool that most Java programmers don't know about yet! JPython isn't a competitor to Java, it's the perfect complement to it. Java is a statically typed, compiled language. This ensures type-safety of libraries and fast execution speeds. Although it is bytecode interpreted, most people view Java through the traditional write-compile-run-edit programming cycle. Of course, Java leverages a huge segment of the software world, so there are a lot of resources available to the Java programmer. But the same static typing and traditional programming cycle are what increases the cost of Java application development in terms of human resources. And here, Python absolutely excels. Because Python is such a simple and small language, it's very easily to learn (many experienced programmers can learn enough Python to be productive in about a day). And Python was designed with the observation that code is read many times more than it is written, so Python code is easy to share in a large team project. More importantly, Python is a very high-level dynamically typed language. What this translates to is the savings in amount of code needed to perform a task, as I alluded to above. With Python, because I can write many fewer lines of code, I can write them faster and have fewer bugs. This is wonderful for rapid application development. Python also provides an interactive interpreter. This means that you can sit at the interpreter prompt, import Java code, create instances, make method calls, etc., all interactively. This is a wonderful tool for training programmers on the use of corporate Java libraries, or for experimenting with new Java APIs. You also asked what's wrong with the original CPython? Well, nothing! IMO, all programmers should have both CPython and JPython in their arsenals :). Q. What strengths or advantages does JPython have over CPython? Or over Stackless, Vyper, Python.NET, if you have any opinions about those? What weakness or disadvantages does it have? What CPython lacks is access to the vast amount of Java code out in the world. If there are Java libraries you need to use, JPython is the answer. Conversely of course, JPython doesn't have easy access to any existing C libraries out in the world. Finn Bock has done work integrating things like Tkinter and a posix module through JNI, but those will always be non-standard in JPython because we want to retain the 100% Pure Java certification. I don't have any direct experience with Stackless, Vyper, or Python.NET except what I've read about them. I'm personally glad they all exist because it proves the immense attractiveness and clarity of Guido's language. Q. Since JPython combines Java and Python, in a certain sense, what strength and advantages does JPython have over Java? Likewise, weakness and disadvantages? Again, I think these have been covered above. I'll just briefly mention performance issues with JPython. Since JPython implements Python's dynamic semantics, there is a fairly extensive run-time that comes with JPython. This can have a performance impact on some applications. Standard Java optimizations such as just-in-time compilers and Hotspot technology can mitigate those considerably (e.g. benchmarks 8 months ago showed that with a JIT-enabled JVM, JPython 1.1 could approach and sometimes surpass CPython 1.5.2 speeds). We'll be updating those benchmark results, and concentrating on performance issues after we roll out JPython's successor (more on that below). In analogy to CPython, you can always rewrite performance critical sections of your application in Java. Q. How widely used do you think JPython is? Are there particular industries or types of problems that are a particularly good match for JPython? I think it's becoming more and more widely used. The companies that are using it find that it's a technology critical to their success. JPython is valuable to them for all kinds of tasks, from providing an approachable scripting environment to their end users to making it easy to create testing frameworks for their Java libraries and applications. JPython's biggest disadvantage at the moment is that it needs more publicity. I hope this article will help in that department! Q. Two technical matters surrounding JPython have particularly struck me in discussions on the Python newsgroup. I was hoping you might weigh in on either of these: (1) There is a lot of talk about the fact that JPython uses true garbage-collection, while CPython uses reference counts. Do you believe this is an advantage of JPython, or simply an implementation requirement of Java? Do you think CPython 2 (or Python 3000) should go in the JPython direction? Intelligent programmers can disagree about this, and both approaches have their advocates and detractors. The bottom line is that JPython has no choice in the matter, while in C there's no portable way to do general garbage collection if you want to be able to link in third party libraries. So neither approach will change, and this is just one area of the Python language that's implementation dependent. Reference counting has the advantage that collection time can be predicted, and finalizers can be used to free external resources. This is used in CPython quite a bit. There are programmers who rely on such behavior because they can easily understand what is going to happen, and when. While Java defines (in gory details) the finalization semantics in its garbage collected environment, the practical result is that Python programmers cannot rely on finalization (i.e. __del__() methods) to reclaim external resources. This issue is really much more relevant to extension writers, i.e. programmers who are writing Python extensions in C or Java. The CPython extension writer has to explicitly increment and decrement the reference counts, and this can lead to memory leaks or crashes if not done properly (fortunately CPython's reference counting rules are explicitly spelled out). The JPython extension writer on the other hand, has a much easier time because Java just takes care of things. In the end, reference counting vs. garbage collection are just two different valid memory management schemes. Both work well in their own context, if you understand the pros and cons. So the Python language definition must remain neutral on the subject of garbage collection and object finalization. Note that CPython 2.0 will have optional garbage collection of cyclic data, a bane of some types of applications for a long while. While this isn't the same as Java's garbage collection, it means the CPython programmer, like the JPython programmer, now no longer has to worry about explicitly breaking cycles. The interesting outcome is that, in the face of cycle collection, CPython's own finalization rules become problematic. (2) Christian Tismer's Stackless Python seems to have generated a lot of excitement among Python users; many have argued that his patches ought to be integrated into core CPython. One argument raised against this change in CPython is that it is not possible to fold the same changes into JPython, and keeping the versions in accord is important. Do you think the technical appraisal of incompatibility between JPython and Stackless Python is accurate? If so, how important do you think keeping JPython and CPython compatible at this level is? Underlying this question is whether JPython is an attempt to keep up with CPython, or whether the two are co-equal implementations: opinion? I haven't really had the time to look very deeply at the technical details of Stackless. People who have tell me it's impossible, but then Jim Hugunin was told JPython was impossible, and look what happened there! In any event, it would be a large amount of work. On a philosophical note, Stackless provides the ability to do coroutines, generators, and micro-threads. Whether continuations themselves can ever be supported in JPython doesn't mean we can't support these higher-level abstractions in different ways, with a common API. I don't know if that's true, but it would be a worthy goal. As long as these constructs are implemented in the library and not as core language features, I don't think it would have much impact on JPython. I firmly believe that at the language level, JPython and CPython ought to be completely compatible. Where this is impossible, Guido will decide whether the differences are implementation dependent, or whether one or the other implementations are "buggy". I would eventually like to see both CPython and JPython become co-equal, with JPython pushing CPython development in certain directions as much as CPython pushes JPython. One current example of this is in Unicode support. CPython currently has two string types, an 8-bit string and Unicode strings. 8-bit strings double as binary data holders. In JPython, there are only Unicode strings (built on Java strings). So this is an area where JPython is helping to resolve issues surrounding unification of the string type in Python. Another example is the types/class dichotomy. In CPython, you have built in types like strings, dictionaries, lists, and numbers. You also have classes and instances. The built in types can't be inherited from, and to add more confusion, an instance has both a type and a class. It may be easier to fix this rift in JPython first because of its object-oriented implementation language. Q. What, if any, significant incompatibilities exist between JPython and CPython? How easy am I likely to find moving application code between the two implementations? What are the major gotchas? The next version of JPython will be compatible with the Python 2.0 language definition, so the biggest gotchas will be in the libraries. Any of the standard library modules from the CPython distribution that are written in pure Python should be portable. C extension modules will not be, unless they are specifically integrated through a JNI bridge, or re-implemented in Java. And any JPython application that extensively uses Java APIs will have a hard time porting back to CPython. On the other hand, there is a lot of common functionality in the libraries of the two systems. With sufficient foresight, compatibility layers can be built into your application. There are numerous small differences in the way some things work. These are outlined in the JPython documentation. Again, some are classified as acceptable differences given the language definition, and some point out places where one or the other implementation ought to be fixed. Most are quite minor. Q. Are there other aspects of JPython that I have not asked about, that you think "Charming Python" readers should know about? There have been a lot of concern on the various newsgroups and mailing lists about the fate of JPython, especially with our move to BeOpen.com and the licensing struggles with CNRI. I'd like to use this opportunity to let the community know that JPython is alive and well, albeit with a slightly new identity. Probably by press time we will have released an alpha version of JPython's successor, to be called Jython 2.0. The entire development process will be opened up and moved to SourceForge. It'll be developed and managed using the same kind of open process that is working so well for CPython. JPython's savior through these rough times, Finn Bock, is and will remain intimately involved in Jython's future development. This should help ensure Jython's continued availability and success. We'll have new mailing lists homed at pythonlabs.com for discussion of the Jython releases. Q. Any thoughts on future directions for JPython? Anything new and different expected down the pipeline? Finn Bock and I have been working on several technical milestones for the Jython 2.0 release, including integrating Finn's errata, updating Jython to support CPython 2.0 language features, integrating the free Apache Jakarta OROMatcher code (thus eliminating the need for dual licensing), and fixing lots and lots of bugs. The first alpha release may be incomplete in some of these areas but they'll all be finished by the time Jython 2.0 is released.