Attendees

Agenda

Day 1

Day 2

Pending

Day 1

Status of python3 third-party modules 1

Brief discussion on this topic. Deferred further discussion for two reasons:

  1. bento maintainer and distutils2 maintainers present for tonight. Talk to them about issues which concern them.
  2. Allison Randal not present tonight

Have to engage upstreams

How do we market to upstream that we (distro maintainers) want to help create patches for python3?

gtk/gnome

setuptools

Actions

Multiple versions 1

Goals

Any solution has two parts -- what do we do in python and what do we do in the distros.

A current solution

Caveats

A new ENVVAR specifying config files

Why not just use PYTHONPATH?

The location of the package will need to depend on both the python package name and its version. For instance: /usr/lib/python2.7/site-packages/foo-1.0/foo This location specifies and exact version. PYTHONPATH would require us to specify that exact version as well: PYTHONPATH=/usr/lib/python2.7/site-packages/foo-1.0/foo. This will break the moment we upgrade to a different version of foo even if it's API compatible. Using a config file means that we get a range of versions.

Questions

Actions

Duplicate named modules

Problem, sometimes there's more than one python module that shares the same name. then we have to get someone to rename modules.

Actions

Numpy

Quick questions about packaging best practices and the FHS.

Namespace packages

Some questions about how namespace packages will affect python

Licensing issue

Paul Hildebrandt asked about meeting with Matthias Klose and Van about licensing concerns for Lib/profile.py and Lib/pstat.py. Unfortunately, van was not around and Paul was worried it would have to wait another year for resolution (next PyCon).

Action

Day 2

Bento & distutils2 discussion

Action

Byte/unicode issues on python3

Surrogate escape

Problem

We now have surrogateescape being used to deal with undecodable bytes on system interfaces (for instance, os.listdir, os.environ). Strings that are decoded using this throw a traceback when printed output to files (or otherwise leaving python's control) unless we explicitly change the errors method to use surrogateescape (to reencode the data properly). The question is how is this better than the python2 byte str which would sometimes traceback when implicitly being converted to unicode.

Rationale

Talked to Martin and came up with the idea that as long as the surrogateescaped string remains within python or output to the same sort of system interfaces as it was created with (os.environ, open and other filesystem interfaces) there are no tracebacks, things simply work. Programmers are going to have to deal with undecodable bytes when they transfer it to a different type of interface (outputing into a file, printing to the terminal) anyway, so a traceback is appropriate at that point.

The best practice for programmers needs to evolve. Programmers will need to convert between surrogateescaped strings and strings escaped in a unicode compatible manner (xmlescaped byte value, etc). The two options that seem immediately present are to convert immediately upon getting the values (then the programmers can check that their code uses system interfaces) and if they have those, then they can transform the strings at that time. If they think that they are going to use those strings in other system interfaces (like grabbing the filename in os.listdir, then opening that file and reading its contents) they'll need to keep the surrogateescaped filename around somehow so it will be more appropriate for them to either stay with the surrogateescape format or store two versions of the filename.

Import of non_ascii module names

Action

PyCon2011/Distro Sprint (last edited 2011-03-14 16:09:27 by ToshioKuratomi)

Unable to edit the page? See the FrontPage for instructions.