Posts Tagged With 'python'
Time for another installment of my ongoing mission to convert the world to
Python 3! This time, a little Debian packaging-fu for modifying an existing
Python 2 package to include support for Python 3 from the same source package.
Today, I added a python3-feedparser package to Ubuntu Precise. What's
interesting about this is that, despite various reported problems, upstream
feedparser 5.1 claims to support Python 3, via 2to3 conversion. And indeed
it does (although the test suite does not).
Before today, Ubuntu had feedparser 5.0.1 in its archive, and while some
work has been done to update the Debian package to 5.1, this has not been
released. The uninteresting precursor to Python 3 packaging was to upgrade
the Ubuntu version of the python-feedparser source package to 5.1. I'll spare
you the boring details about missing data files in the upstream tarball, and
other problems, since they don't really relate to the Python 3 effort.
The first step was to verify that feedparser 5.1 works with Python 3.2 in a
virtualenv, and indeed it does. This is good news because it means that the
setup.py does the right thing, which is always the best way to start
supporting Python 3. I've found that it's much easier to build a solid Debian
package if you have a solid setup.py in upstream to begin with.
Now, what I'd like to do is to give you a recipe for modifying your existing
debian/ directory files to add Python 3 support to a package that already
exists for Python 2. This is a little trickier for feedparser because it used
an older debhelper standard, and carried some crufty old stuff in its
rules file. My first step was to update this to debhelper compatibility
level 8 …
Continue reading »
Yesterday, I completed my port of dbus-python to Python 3, and submitted
my patch upstream. While I've yet to hear any feedback from Simon about my
patch, I'm fairly confident that it's going in the right direction. This
version should allow existing Python 2 applications to run largely unchanged,
and minimizes the differences that clients will have to make to use the Python
Some of the changes are specific to the dbus-python project, and I included
a detailed summary of those changes and my rationale behind them. There
are lots of good lessons learned during this porting exercise that I want to
share with you, have a discussion about, and see if there aren't things we
core Python developers can do in Python 3.3 to make it even easier to migrate
to Python 3.
First, some background. D-Bus is a freedesktop.org project for same-system
interprocess communication, and it's an essential component of any Linux
desktop. The D-Bus system and C API are mature and well-defined, and there
are bindings available for many programming language, Python included of
course. The existing dbus-python package is only compatible with Python 2,
and most recommendations are to use the Gnome version of Python bindings
should you want to use D-Bus with Python 3. For us in Ubuntu, this isn't
acceptable though because we must have a solution that supports KDE and
potentially even non-UI based D-Bus Python servers. Several ports of
dbus-python to Python 3 have been attempted in the past, but none have been
accepted upstream, so naturally I took it as a challenge to work on a new
version of the port. After some discussion with the upstream maintainer Simon
McVittie, I had a few requirements in mind:
- One code base for both Python 2 and Python 3 …
Continue reading »
Earlier this month, I attended UDS-P (the Ubuntu Developers Summit for 12.04
Precise Pangolin). 12.04 is an LTS release, or Long Term Support,
meaning it will be officially supported on both the desktop and server for
During the summit we reiterated our plans for Python on Ubuntu, both for
12.04 LTS, and our vision of Python two years from now for the next LTS,
14.04. I'm here to provide an update from my last report, which was written
after UDS-O for 11.10.
As per those previous plans, we've removed Python 2.6 from Ubuntu 12.04. Now
you have only Python 2.7 and 3.2. Dropping Python 2.6 may cause some
inconvenience for data centers which like to upgrade only between LTS's but
don't want to have to upgrade both their operation system and their Python
version. Canonical services such as Launchpad and Landscape fall into this
camp. The biggest problem is that Python 2.7 is not available for the last
LTS, i.e. 10.04. To mitigate this, we decided to create a PPA containing
Python 2.7 and a bunch of packages that services such as Launchpad will need
to do their porting. This now exists, although it hasn't yet been tested with
any development branches of Launchpad or Landscape as far as I'm aware. If
you have your own data center porting task ahead of you, you can also use this
PPA, and if there are additional packages you need for 10.04, you can create
your own PPA which depends on ours, and build those extra packages there.
But that's all boring stuff. Let's have some fun!
The other decision we made concerns Python 3. I strongly feel that the Python
community is very close to …
Continue reading »
So, yesterday (June 21, 2011), six talented and motivated Python hackers from
the Washington DC area met at Panera Bread in downtown Silver Spring,
Maryland to sprint on PEP 382. This is a Python Enhancement Proposal to
introduce a better way for handling namespace packages, and our intent is to
get this feature landed in Python 3.3. Here then is a summary, from my own
spotty notes and memory, of how the sprint went.
First, just a brief outline of what the PEP does. For more details please
read the PEP itself, or join the newly resurrected import-sig for more
discussions. The PEP has two main purposes. First, it fixes the problem of
which package owns a namespace's __init__.py file,
e.g. zope/__init__.py for all the Zope packages. In essence, it eliminate
the need for these by introducing a new variant of .pth files to define a
namespace package. Thus, the zope.interfaces package would own
zope/zope-interfaces.pth and the zope.components package would own
zope/zope-components.pth. The presence of either .pth file is enough
to define the namespace package. There's no ambiguity or collision with these
files the way there is for zope/__init__.py. This aspect will be very
beneficial for Debian and Ubuntu.
Second, the PEP defines the one official way of defining namespace packages,
rather than the multitude of ad-hoc ways currently in use. With the pre-PEP
382 way, it was easy to get the details subtly wrong, and unless all
subpackages cooperated correctly, the packages would be broken. Now, all you
do is put a * in the .pth file and you're done.
Sounds easy, right? Well, Python's import machinery is pretty complex, and
there are actually two parallel implementations of it in Python 3.3, so
gaining traction on …
Continue reading »
TL;DR: Ubuntu 12.04 LTS will contain only Python 2.7 and 3.2, while Ubuntu
11.10 will contain Python 3.2, 2.7 and possibly 2.6, but possibly not.
Last week, I attended the Ubuntu Developer Summit in Budapest, Hungary.
These semi-annual events are open to everyone, and hundreds of people
participate both in person and remotely. Budapest's was called UDS-O, where
the 'O' stands for Oneiric Ocelot, the code name for Ubuntu 11.10, which
will be released in October 2011. This is where we did the majority of
planning for what changes, new features, and other developments you'll find in
the next version of Ubuntu. UDS-P will be held at the end of the year in
Orlando, Florida and will cover the as yet unnamed 12.04 release, which will
be a Long Term Support release.
LTS releases are special, because we make longer guarantees for official
support: 3 years on the desktop and 5 years on the server. Because of this,
we're making decisions now to ensure that 12.04 LTS is a stable, confident
platform for years to come.
I attended many sessions, and there is a lot of exciting stuff coming, but I
want to talk in some detail about one area that I'm deeply involved in.
What's going to happen with Python for Oneiric and 12.04 LTS?
First, a brief summary of where we are today. Natty Narwhal is the code
name for Ubuntu 11.04, which was released back in April and is the most recent
stable release. It is not an LTS though; the last LTS was Ubuntu 10.04 Lucid
Lynx, release back in October 2010. In Lucid, the default Python
(i.e. /usr/bin/python) is 2.6 and Python 2.7 is not officially …
Continue reading »
I know that the Mailman 3 project is not alone in procrastinating getting
out a release of its major rewrite. It's hard work to finish a rewrite on
your own copious spare time. I was just chatting with Thomas Waldmann of the
Moin project on IRC, and he lamented a similar story about the Moin 2
release. Then he said something that really made me sit up straight:
<ThomasWaldmann> 11.11.11 would be a great date for something :)
Yes, it would! We have the 2011 Google Summer of Code happening soon
(students, you have until April 8th to submit your applications) so many
free and open source software projects will get some great code coming soon.
And November is far enough out that we can plan exactly what a "release"
means. Here's what I propose:
Let's make November 11, 2011 the "Great FLOSS Release Day". If you're working
on an open source project undergoing a major new version rewrite, plan on
doing your release on 11.11.11. It can be a beta or final release, but get
off your butts and make it happen! There's nothing like a good deadline to
motivate me, so Mailman 3 will be there. Add a comment here if you want your
project to be part of the event!
For the last couple of days I've been debugging a fun problem in the Ubuntu
tool called Jockey. Jockey is a tool for managing device drivers on Ubuntu.
It actually contains both a command-line and a graphical front-end, and a dbus
backend service that does all the work (with proper authentication, since it
modifies your system). None of that is terribly relevant to the problem,
although the dbus bit will come back to haunt us later.
What is important is that Jockey is a Python application, written using many
Python modules interfacing to low-level tools such as apt and dbus. The
original bug report was mighty confusing. Aside from not being reproducible
by myself and others, the actual exception made no fricken sense! Basically,
it was code like this that was throwing a TypeError:
_actions = 
# _actions gets appended to at various times and later...
for item in _actions[:]:
# do something
Everyone who reported the problem said the TypeError was getting thrown on
the for-statement line. The exception message indicated that Python was
getting some object that it was trying to convert to an integer, but was
failing. How could you possible get that exception when either making a copy
of a list or iterating over that copy? Was the list corrupted? Was it not
actually a list but some list-like object that was somehow returning
non-integers for its min and max indexes?
To make matters worse, this little code snippet was in Python's standard
library, in the subprocess module. A quick search of Python's bug
database did reveal some recent threads about changes here, made to ensure
that popen objects got properly cleaned up by the garbage collector if they
weren't cleaned up explicitly by the program. Note that we're using Python
2.7 here, and after some reading …
Continue reading »
My friends and family often ask me what I do at my job. It's easy to
understand when my one brother says he's a tax accountant, but not so easy
to explain the complex world of open source software development I live in.
Sometimes I say something to the effect: well, you know what Windows is, and
you know what the Mac is right? We're building a third alternative called
Ubuntu that is free, Linux-based and in most cases, much better. Mention
that you won't get viruses and it can easily breathe new life into that old
slow PC you shudder to turn on, and people at least nod their heads
enthusiastically, even if they don't fully get it.
I've been incredibly fortunate in my professional career, to have been able to
share the software I write with the world for almost 30 years. I started
working for a very cool research lab with the US Federal government while
still in high school. We had a UUCP connection and were on the early
Arpanet, and because we were funded by the US taxpayer, our software was not
subject to copyright. This meant that we could share our code with other
people on Usenet and elsewhere, collaborate with them, accept their
suggestions and improvements, and hopefully make their lives a little better,
just as others around the world did for us. It was free and open source
software before such terms were coined.
I've never had a "real job" in the sense of slaving away in a windowless cube
writing solely proprietary software that would never see the light of day.
Even the closed source shops I've worked at have been invested somehow in
free software, and with varying degrees of persuasion, have both benefited
from and contributed to the …
Continue reading »
Richard Jones is working on a talk for PyCon Australia and asked me
about the history of the Zen of Python, Tim Peters' eternal words of
wisdom, often quoted, on the essential truths of Python. At first, I couldn't
find a reference to the first publication of this list, but then I did a
better search of my archives and found that it was originally sent to the
python-list mailing list on June 4, 1999, under the subject "The Python
Interestingly enough, because I couldn't find that first reference
immediately, I went back into my archives and researched the "this" module.
Did you know that if you type the following at a modern Python interpreter,
you get the Zen of Python?
% python3 -c "import this"
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
The story behind "import this" is kind of funny, and occurred totally behind
the scenes, so I thought it might be interesting to relate how it happened …
Continue reading »
I'm doing some work these days on trying to get Python 2.7 as the default
Python in the next version of Ubuntu, Maverick Meerkat (10.10). This work
will occasionally require me to break my machine by installing experimental
packages. That's a good and useful thing because I want to test various
potentially disruptive changes before I think about unleashing them on the
world. This is where virtual machines really shine!
To be efficient, I need a really fast turnaround from known good state, to
broken state, back to known good state. In the past, I've used VMware Fusion
on my Mac to create a VM, then take a live snapshot of the disk before making
my changes. It was really easy then to revert to the last known good
snapshot, try something else and iterate.
But lately Fusion has sprouted a nasty habit of freezing the host OS, such
that a hard reboot is necessary. This will inevitably cause havoc on the
host, by losing settings, trashing mail, corrupting VMs, etc. VMware can't
reproduce the problem but it happens every time to me, and it hurts, so I'm
not doing that any more :).
Back to my Lucid host and libvirt/kvm and the sanctuary of FLOSS. It's
really easy to create new VMs, and there are several ways of doing it, from
virt-manager to vmbuilder to straight up kvm (thanks Colin for some
recipes). The problem is that none of these are exactly fast to go from
bare metal to working Maverick VM with all the known good extras I need (like
openssh-server and bzr, plus my comfortable development environment).
I didn't find a really good fit for vmbuilder or the kvm commands, and I'm not
smart enough to use the libvirt command line tools, but I think …
Continue reading »