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.