[Python-Dev] EuroPython Language Summit report

[Mark Dickinson]

EuroPython 2011 Language Summit
===============================

Here's a brief report on the EuroPython 2011 Language Summit, held on Sunday 19
June, 2011 in Florence.  It was a fairly small meeting, with a lot of informal
and loosely-focused discussion and few conclusions reached.  I've outlined the
topics that we discussed below.

Present:

    Antonio Cuni
    Mark Dickinson
    Larry Hastings (chair)
    Marc-André Lemburg
    Ezio Melotti
    Antoine Pitrou
    Armin Ronacher
    Armin Rigo
    Mark Ramm

Topics covered
==============

Python 3 adoption
-----------------

This was a long and wide-ranging discussion on the general state of Python 3
adoption.  Some highlights:

  - Even amongst those present at the meeting, most are still using Python 2
    for everyday work.

  - pypy: no definitive plans yet for PyPy supporting Python 3.

  - The web community is still very much focused on Python 2.

  - There's ongoing work (or perhaps just discussion?) on being able to
    generate Python 3 documentation using Sphinx running on Python 3.  This
    would be particularly useful when using extensions like 'autodoc' for
    Python 3 code.

  - [Armin Ronacher] Python 3's Unicode support still has some dark areas.  One
    example: when opening a text file for reading and writing, the default
    encoding used depends on the platform and on various environment variables.

  - Regular expression support in Python 3 needs improvement (support for
    Unicode character classes is a particular need).  [Subtopic:  what needs
    to be done to get the new regex module into Python?  Should it replace
    the existing module?  What about backwards compatibility issues?]

  - 2to3:  It's still painful to upgrade a codebase from Python 2 to Python 3,
    and there doesn't seem to be a consensus on best practices yet.

There was a long discussion that I can't hope to do justice to on whether 2to3
should be part of the standard library or not.  (With side discussions on
distutils and packaging in Python 3.)  Armin Ronacher was one of the main
participants in this discussion (and IIUC, the main opponent of having 2to3 in
the standard library); Armin, do you want to summarize this?

Another major topic of discussion was on how to manage Python 2 and Python 3 in
plugin environments (e.g., Blender): is there some way that both Python 2 and
Python 3 plugins could be used within the same system?  This got a bit
technical; perhaps someone else at the meeting would like to elaborate on this?

State of Python 3 on the web
----------------------------

Brief discussion.  Summary: it's improving; better than before.  We have
CherryPy and WSGI.  There are issues in WSGI that are going to become more
apparent as more people move to Python 3 frameworks.

Discussion of open PEPS
-----------------------

PEP 3151: (Reworking the OS and IO exception hierarchy.)  Antoine summarized
    this; no real discussion here.

PEP 3118: (Not open, but ...)  Revising the buffer protocol.  The buffer
    protocol implementation is still buggy and incomplete.  (Mostly okay for 1d
    buffers, not even close for higher-dimensional work.)

PEP 397: Python launcher for Windows.  (This was actually discussed later,
    after lunch; apologies for messing with the timeline here.)  There was some
    confusion over the purpose of this PEP.  Armin Ronacher had some objections
    to the PEP in its current form, but it's not clear to me what those objects
    are, or whether they still exist.  Armin, care to elaborate?

PEP 0380: Syntax for delegating to a subgenerator.

PEP 3150: Statement local namespaces.

PEP 3152: Cofunctions.


For all three of the above PEPs, there was some feeling that additional syntax
changes to the language are unnecessary and make it harder to learn; where
possible, we should prefer using 3rd partly libraries.

Issue 12326 (Linux 3)
---------------------

>From the issue report by Charles-François Natali::

    Linus recently decided that the next Linux kernel version would 3.0 [1].
    As a consequence, sys.platform (which is actually MACHDEP) will be 'linux3'
    on machines running Linux 3 kernels, and tests checking explicitely against
    'linux2' will either break and won't run.

There was significant discussion on how this should be solved.  While there's a
lot of discussion already on the tracker, the choice of solution may have
significant ramifications, so it seems a good idea that this be discussed more
widely on python-dev.

Major questions::

- what should be done with Python 2.7?  As it stands, as I understand it,
  sys.platform *will* become 'linux3' on Linux 3.x (it's a computed value
  somewhere) in Python 2.7.2, and since Python 2.7.2 is already out there we
  can't change that.  Some of the proposed solutions to the issue would
  involve sys.platform changing between Python 2.7.2 and Python 2.7.3; is
  such a change acceptable for a bugfix release?

- it's easy to fix up all uses of "== 'linux2' " in the standard library; is it
  okay to just let 3rd party code break here?

- What should be done about Lib/plat-linux2?


The rough consensus at the summit was that for Python 2.7 at least, the only
realistic solution seems to be to do nothing except document the problem, and
point people to the platform module.  I'm not sure if this answers the
Lib/plat-linux2 question.

Python 2.7
----------

How long will this be maintained?
Original decision was 5 years.


PyPI on EC2
-----------

There was some discussion several months ago about the possibility of hosting
PyPI on EC2.  Is this still something that should be considered?  PyPI seems to
have been much more problem free in recent times.


virtualenv in Python 3.3?
-------------------------

Apparently there was some discussion at the last PyCon about the possibility of
virtualenv going into Python 3.3.  As far as I know there's currently no open
tracker item or PEP for this.  Larry Hastings knows more here.

-- Update from Larry: """I'm supportive of putting it in in 3.3, and I'm
   sitting with Raymond Hettinger right now and he supports it too.  So I think
   if we get a working implementation it'll go in.  It's under heavy discussion
   in c.l.p-d so I gather it's moving forward.  Last I knew it was Carl Meyer
   pushing it forward, but Vinay Sanjip is the current standard-bearer.  I
   understand Windows support will be a bit tricky; I don't know if they have
   someone who's going to handle it for them."""

Python website
--------------

The Python website is painful to edit right now.