-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jul 13, 2006, at 2:03 PM, [EMAIL PROTECTED] 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. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iQCVAwUBRLanoHEjvBPtnXfVAQJB6gP/SwVtejenN0/7tszePbJ4O20l98k2Z/7N rs9dfF2+Jcy/OLzSCcW/OW4iVf+iPJMWUNqHEPFDQO/+nVifh8pjjWGTQJMc8ynm 7HNCk/ZciZyNqeGbmGvzHoywmrldbDPkx5Y6Fo13yel0slw2Qo6gC6W8aygi7giP boJiovnaKH0= =wRxy -----END PGP SIGNATURE----- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
