[Python-Dev] Community buildbots (was Re: User's complaints)

glyph at divmod.com glyph at divmod.com
Thu Jul 13 20:03:22 CEST 2006


On Wed, 12 Jul 2006 10:30:17 +1000, Michael Ellerman <michael at ellerman.id.au> wrote:

>Well here's one I stumbled across the other day. I don't know if it's
>legit, but it's still bad PR:
>
>http://www.gbch.net/gjb/blog/software/discuss/python-sucks.html

Having been exhorted (or maybe I mean "excoriated") by your friendly release 
manager earlier this week to post my comments and criticisms about Python here
rather than vent in random IRC chatter, I feel morally compelled to comment.

I see some responses to that post which indicate that the specific bug will be
fixed, and that's good, but there is definitely a pattern he's talking about
here, not just one issue.  I think there is a general pattern of small,
difficult to detect breakages in Python.  Twisted (and the various other
Divmod projects that I maintain) are thoroughly unit-tested, but there are
still significant issues in each Python release that require changes.

Unlike the jerk who posted that "python sucks" rant, I'm not leaving Python
because one function changed in a major release; I do expect to have to
maintain my projects myself, and major releases are "major" for a reason.  I
only wish that upgrading all my other dependencies were as easy as upgrading
Python!  I do see that the developers are working with some caution to avoid
breaking code, and attempting to consider the cost of each change.

However, although I've seen lots of discussions of what "average" code might
break when exposed to new versions of Python, these discussions tend to be
entirely hypothetical.  Do the core Python developers typically run the test
suites of major Python applications when considering major changes, such as 
Zope, Plone, TurboGears, and of course Twisted?  Not that breakages would be
considered unacceptable -- some gain is surely worth the cost -- but to
establish some empirical level of burden on the community?

I would like to propose, although I certainly don't have time to implement,
a program by which Python-using projects could contribute buildslaves which
would run their projects' tests with the latest Python trunk.  This would
provide two useful incentives: Python code would gain a reputation as
generally well-tested (since there is a direct incentive to write tests for
your project: get notified when core python changes might break it), and the
core developers would have instant feedback when a "small" change breaks more
code than it was expected to.

I can see that certain Python developers expect that some of this work is the
responsibility of the user community, and to some extent that's true, but at
least half of the work needs to be done _before_ the changes are made.  If
some Python change breaks half of Twisted, I would like to know about it in
time to complain about the implementation, rather than flailing around once
the Python feature-freeze has set in and hoping that it's nothing too serious.
For example, did anyone here know that the new-style exceptions stuff in 2.5
caused hundreds of unit-test failures in Twisted?  I am glad the change was
made, and one of our users did catch it, so the process isn't fatally broken,
but it is still worrying.

Another problem is simply that the Python developers don't have the same
very public voice that other language developers do.  It doesn't necessarily
have to be a blog, but python-dev is fast-paced and intimidating, and a
vehicle for discussion among those in the know, rather than dissimenation to
the community at large.  It's a constant source of anxiety to me that I might
miss some key feature addition to Python which breaks or distorts some key bit
of Twisted functionality (as the new-style exceptions, or recent ImportWarning
almost did) because I don't have enough time to follow all the threads here.
I really appreciate the work that Steve Bethard et. al. are doing on the
python-dev summaries, but they're still pretty dry and low level.

While the new python.org is very nice, I do note that there's no "blogs" entry
on the front page, something which has become a fixture on almost every other 
website I visit regularly.  The news page is not very personal, mainly a 
listing of releases and events.  There's no forum for getting the community 
_excited_ about new features (especially new features which are explicitly 
enabled by potential breakages), and selling them on the cool uses.  Who 
knows, maybe I'll even start using decorators syntax all over the place if I 
see them presented somewhere by someone who is very excited about the feature 
and thinks it's worthwhile, rather than as a defense on a mailing list 
against a criticism, or a simple announcement of the feature's existence.

I've seen the other side of this problem as well, so I can appreciate that it
is quite difficult to get this kind of thing right: lots of applications using
Twisted break when we change broken or deprecated APIs.  Twisted is lucky
though; it has numerous subprojects, and I maintain a half-dozen unrelated
projects in a different repository.  Twisted itself is a fairly
representative "application using Twisted", so when something breaks "average"
Twisted code, I know about it right away.  Python is less an application using
Python: the standard library is rather passive (there is no "end-to-end" 
application path to test, only individual functions and classes), and the test
coverage of included Python modules is rather spotty.

I hope someone finds some of these suggestions helpful.  I only wish I had the
time and energy to act on some of them.


More information about the Python-Dev mailing list