Day one of PyCon and I spent the whole day at the language summit. This post contains the notes I took during the day.

Pypy (Armin Rigo)

PyPy works :) 10th anniversary was few days back , 2.0 is coming. More near to c extension modules. Alpha version targeting Python 3.2 will come in. Currently buildbot has around 20 modules fail in the same.

Both python 2.7 and python 3 will be supported. Greenlets or stackless support, it is fast now. Gambit research paid for greenlet support work to fijal.

Code wise rpython is now different, pypy uses rpython as a library. Final goal is to split it out. STM: attempt to remove GIL, it kind of works, it leaks memory now.

Philip (Jython)

Jython 2.7 beta 1 released last month. No python 3 support yet, but the developers really want to work on it. Utilizing Java 7 features is yet to be done.

Ironpython (Jeff Hardy)

2.7 is there for couple of years. Not many contributors. Trying to get whole .NET plugins directly be used in ironpython. It is on github as apache2 license. Developers like to get Python3 support this year.

Nick Coghlan (packaging)

There will be many packaging changes. Just convince him and he will figure the required people for peps. around half dozen projects on packaging standard. The new approach is to evolve the echo system than changing the world.

setup.py install must die. It should go away, metadata 2.0 can be the future, move installation and metadata move away from setup.py

Lot of metadata peps important people to accept them are not python devs. setuptools, distribute, zc.builtout, condor etc they need to approve the metadata standard.

Decouple buildsystem from the tool people choose to install the software. Metadata 2.0 is to clearly differentiate between installer and buildsystem.

Metadata 2.0 will have one post-install hook, there will be sane API. All discussions on metadata is on distutils-sigs, people are frustrated as discussion needs to happen in distutils-sig and also python-dev lists.

Nick wants to change the away PEPs get approval. The PEP on metadata stuff should happen in distutils-sig only.

People in the summit agreed on sub-topic mailing lists as discussion places.

Related peps: 426

Brett Cannon (XML issues)

Lot of problems in XML. People were saying "If you are accepting unsafe data you should check it before using it". Should be turned on in 2.7 also (the monkeypatching code from Christan) or not was the main discussion. People talked about many use cases which we might break if we turn it by default. Alex reported that Django project is keeping in touch with Christian on XML issues.

Guido van Rossum (tulip)

PEP380 was "yield from". Incredibly easy and difficult at the same time. We can do better with "yield from". Start a fresh in the standard library and wanted to have an unified event loop. All in PEP3156. there is a standard interface which everyone can use, one such implementation must be in the stdlib, different library can provide their own implementation.

Trent Nelson (Parallelizing the python interpeter)

Talked about his love for microsoft products and snakebite project details.

http://hg.python.org/sandbox/trent px branch

Two parts

• Parallelizing the interpreter
• true "asyncchronicity"

Work started from late December (full time until mid Feb-ish). Code is in prototype condition. Only works on Vista+ (for now) Aim is to get everything working first and then refactor/review, review support for other platforms etc.

My favorite line from the talk is about telling one good thing about Windows is that it will not change :p

All existing solutions on table are mostly "paradigm shift" but most of the users and Guido does not want a paradigm shift.

Then he talked about www.snakebite.net project, check the about page for more information.

PEP 436 (The Argument Clinic DSL) Larry Hastings

It is a working prototype. DSL as in comments to the c functions. Mostly people ignored it in python-dev. Stephen's competing PEP, Nick is now reviewing it 0437. Step 1. Build vanilla python step 2. make the changes step 3. use the vanilla python3 to recreate the .c files from the DSL

Alex Gaynor (CFFI)

Proposal is to include cffi in the stdlib.

Ctypes is bad, complex API.

CFFI will help not segfaulting by using compiler. It uses the compilers to verify the signatures. The scope here is calling C. It is doing verify during setup.py level. hash inside verify method. Broken down to compile step to generate cache step, load step to fail if no cache. Runtime to load only

Proposal is not deprecating ctypes. (fijal) while answering to one of Barry's question.

Too early to put in standard library as Thomas thinks , Nick thinks 3.4 is still an option for it. Standard question on python-dev, I crashed python, did you import ctypes ? come back when you don't and still crash :D ctypes has lots of overhead in import so it will be hard to slower than ctypes. ply is good be in stdlib (bdfl). Putting things in stdlib and then telling it is implementation details is not good. answering eli.

Go through the unfortunate world, users don't have c compliers and want to use it. (Ned)

Mathias Klose

3.3.0 is first to cross build for different architectures. backported to 2.7. Changes were in configure stuff, extensions to the stdlib.

get rid of access to sys modules, replaces sys.platform to host.platform, get the information from sysconfig.

Difficult to do cross builds, people tend to break things. make cross test, for particular build slaves, not to run make test but only cross

Robert Collins

Working on various tests suites. shift our norms on test, less comfortable.

Barry Warsaw

keep it simple or support every usecase you can think of. -- different dimensions Derived from int or act like an int in all cases. PEP 435

We will give you couple of simple things and then build complex things using meta classes. (Guido) pointed that out and One enum in stdlib, may be a BDFL.ENUM :D

Large chunks will benefit from it.

Larry informed at the very end that Kenneth is ok to have requests in stdlib. New implementation on the same API on top of tulip (Guido) as everyone agreed that requests is awesome API but needs reimplementation.

At the end Nick also suggested to have a legacy index in the docs which can clearly tell readers that don't use this in the new code.