The day started with introductions. Guido introduced himself as its all his fault.
Release management discussion
Larry Hastings started the day with discussion on 3.5 release. 3.4 release was actually in 16 months. He wanted a feedback on the next release, if we want it in a smaller release cycle than the usual 18 months. Guido mentioned to stay with the 18 month cycle.
Larry also asked about opinions on state of the SCM after release candidate 1, should we create 3.5 branch and if yes then should we allow people to commit there or not? Default should point to 3.5.1 or 3.6 at that time? There can be another scenario where we do not create the 3.5 branch and keep the default as 3.5 release itself. The discussion will continue in the mailing list.
Next topic in the agenda was reports from different implementations.
Alex Gaynor gave us the current status of PyPy project. There will be a second fund raiser on STM. The next release is targeting 2.7.6, there were a million downloads. While discussing about Python 3 branch he explained that it it only 3 bugs away from shipping and it is based on 3.2.
There was a small discussion about state of CFFI for standard library inclusion. Alex and David Beazley are supposed to work on cleaning PLY for the same. General opinion was that it should not be hidden as a private part of the standard lib.
Dino Viehland talked about the status of Ironpython project. Development is going on both 2.7 and 3.x series. 2.7.4 was released last year. Many new contributors came into the project which is a good news.
The developers sent a detailed report to Micheal Foord and he will forward it to the python-dev list. The takeaways from the mail are
- Small number of contributors is a big problem.
- 2.7.beta2 is tagged which used Java7.
- Buffer protocol work is done (foundation to Python3 support).
- They are also working on PyPi tooling.
- There is also hope for releasing CFFI backend for Jython during Europycon sprints.
No standard library as module
When it was asked that if the other implementations want the standard library as a separate module to be resused, all agreed as ‘No’.
It was the longest discussion which made hungry developers really hungry :) Jokes aside, Nick Coghlan gave a detailed report on the advancement of the packaging world. Most of the development/design discussions are now happening on the distutils sig and in pypi mailing lists. He managed to put the use cases a very broader audience now, so we can except better feedbacks. On the development side, Warehouse is now implementing all old API(s), you may want to try it out at https://warehouse.python.org/.
3.4 has pip included, one usecase was to help people who downloads binary installers from our site. They can now install Django or other projects in wheel format.
Everyone also agreed that having the buildsystem inside the language is a bad idea. The buildsystem should be able to do cross-version builds.
Nick also pointed us to http://packaging.python.org/ which is the documentation for the whole echosystem. We all agreed that the Python echosystem is bigger than the core interpreter.
Glyph wants a PSF fund to a usability study on Python. There were a few other suggestion on PSF support for tooling development.
Kevin Modzelewski explained how they are rebuilding a complete vm which is targeted to Python, this also means too much work but one can customize. It is targeting Python2.7 as Dropbox runs on it.
At this time of discussion Nick pointed us to http://speed.python.org/, target is to have a common set of tests to benchmark different implementations. He asked if any of the implementations wants to maintain it. We need more volunteers for that. A common set of cross-implementation benchmarks stays at http://hg.python.org/benchmarks and the mailing list for discussion is at https://mail.python.org/mailman/listinfo/speed.
Notes from teaching and outreach
Selena Deckelmann talked about few pain points from teaching and outreach.
- Website is confusing. (Should I go for Python2 or Python3?)
- Packaging and installer problem
- So many different bug tracking system is also confusing
- OPW program for Cpython, this is the first year we are participating.
- Jessica McKellar will write “brand new coder tutorials”.
Matt Mackall talked about Mercurial’s painpoints for Python3. It currently works for 2.4-2.7, though he might drop 2.4 support in near future. It will be on 2.7 till RHEL7 is not EOL. He also said startup time is concern for him. Only big positive point he can see in Python3 is SNI. That feature allows you to do HTTPS to non ip based virtual hosts. Porting whole Mercurial to Python 3 is still a very big work. They had two gsoc students in last two years.
From here the talks suddenly moved into mythical Python 2.8 which we will not have, nope, sorry :) Guido wants a feature list from the people who are asking for 2.8 to understand better. We also want to help developers to make a single source for Python 2 and Python 3 release less painful.
Python 2.7 is alive and in good health and support will continue on the same.
Few points were talked about from 3.5, like byte formatting, unicode surrogate, binary mode cleans for bytes etc.