On 4/28/07, Leo Usercodecswise I haven't made a detailed analysis of the whole thing besides that its wanting in codecs and doesn't appear geared towards the new Unicode exceptions.
> I believe there are implementations of all language changes from 2.3 to 2.5
> on svn. Yield as an expression is still in progress, really that's just a
> question of finding places where using it as an expression is going to cause
> problems. For the most part classical byte code output is ok. When its not
> ok is say when a new object is being constructed and you have a yield
> expression as one of the parameters. Then something different has to
> happen. Im planning on doing 2.6 features as soon as they are finalized by
> the python PEP for 2.6. Maybe something like switch statements will show up
> once its put together.
This should be of interest to the summer of code crew working on
improving the compiler and getting to 2.5 language level support.
Since they're replacing the parser with ANTLR and CodeCompiler.java
with asm it won't be directly applicable, but at least the way the
newer language features hook into the runtime should be similar.
> There are java translations of python c modules itertools, collections,
> _csv, _functoolsmoudle and _heapqmodule out there. Im currently looking
> into making a modern _codecsmodule, and am sketching out the bz2 module.
> Each one of these seems to help out in implementing other pieces. There
> wouldn't be a 2.5 heapq module out there if itertools wasn't in place.
We've already picked up a really nice version of itertools, but
acquiring the other modules you've already ported would be great.
What do you need to modernize in _codecs? There were big changes from
2.2 to 2.3, but I brought those over ages ago on the 2.3 branch.
Where did you end up with your optimizations to Java method invocation?