-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jul 13, 2006, at 2:03 PM, email@example.com wrote:
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.
And I'm glad you did because you made some excellent comments.
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 do plan on very soon running Mailman's meager test suite and running more manual functional tests on Python 2.5b2. Compared to Twisted, Mailman is pretty simple and doesn't do that much fancy stuff so I suspect that it'll mostly work, but you never know until you try it. I'd support adding Mailman to a community buildbot army, although I don't personally have the cycles to build out such a beast.
I also plan on testing my Real Job's embedded application against Python 2.5b2 sometime this week or next. We're on Python 2.4.2 atm and that is much more complicated because of all the C API we use. I'm less sanguine about breakage there, but I'll post here if I find anything egregious (fortunately, we have an extensive test suite to rely upon).
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.
This really is an excellent point and makes me think that we may want to consider elaborating on the Python release cycle to include a gamma phase or a longer release candidate cycle. OT1H I think there will always be people or projects that won't try anything until the gold release, and that if we've broken anything in their code we simply won't know it until after that, no matter how diligent we are. OTOH, a more formal gamma phase would allow us to say "absolutely no changes are allowed now unless it's to fix backward compatibility". No more sneaking in new sys functions or types module constants <wink> during the gamma phase.