Re: [Python-Dev] why duplicate output lines in verbose tests?
Guido van Rossum python.org> writes: > > On Tue, Aug 12, 2008 at 11:32 AM, Bill Janssen parc.com> wrote: > >> Is it using fork()? Threads? > > > > No on fork(), yes on threads. > > Hmm... I don't believe that io.py is thread-safe. There is an issue open for the BufferedWriter + threads problem (which is probably what causes Bill's problem above). http://bugs.python.org/issue3476 As Martin suggested in this issue's comments, a simple fix would be to wrap most methods with an instance-specific mutex. I don't know how that would affect performance. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
On 2008-08-13 07:53, Martin v. Löwis wrote: Because there won't typically be sufficient testing and release infrastructure to allow arbitrary bug fixes to be committed on the branch. The buildbots are turned off, and nobody tests the release candidate, no Windows binaries are provided - thus, chances are very high that a bug fix release for some very old branch will be *worse* than the previous release, rather than better. Second, I don't think this is true. People using those patch level releases will test and report bugs if they are introduced by such backports. They might be using releases, but they are *not* using the subversion maintenance branches. Do you know anybody who regularly checks out the 2.4 maintenance branch and tests it? So at best, people will only report bugs *after* the release was made, meaning that there is a realistic chance that the release itself breaks things. I think that's an overly pessimistic view. There's always a chance of breaking things when patching anything - whether that's a security fix or a fix for a bug that's hard to work around in an application using Python. Note that those fixes will usually be backports from a more recent release, so even if they don't receive enough direct testing on the older branch before the release is cut, they will get their share of testing either in the context of the more recent branch. As for using the releases themselves: there have been 80462 downloads of 2.4.5 since it was released in March, as compared to 517325 downloads of the 2.5.2 MSI in July alone. So I'm skeptical that many people do actually use the 2.4.5 release. It's difficult to use such download numbers as hint for the number of deployed installations. 2.4.5 was not released as binary, so interested parties had to compile that version by themselves and those installations don't show up in your statistics. I'm sure that if we had released binaries as well, the number would have looked different, esp. if you only look at the Windows binaries. Besides, developers backporting such changes are diligent enough to test their changes - they will usually have a reason for applying the extra effort to backport. My problem is that this backporting is not systematic. It's arbitrary whether patches get backported or not. Part of the problem is that it is/was also unclear whether there ever will be another release made out of 2.4. That's a valid point, but does this really warrant backing out changes that have already been applied ? Isn't it better to get at least some bugs fixed rather than to not fix them at all ? When 2.4.4 was released, Anthony announced, in http://mail.python.org/pipermail/python-dev/2006-October/069326.html "This will be the last planned release in the Python 2.4 series" So anybody committing to the 2.4 branch after that should have expected that the patches will never get released. Perhaps we should just document the maintenance of Python releases more clearly and also plan for a final bug fix release 3 years after the initial branch release. That way developers and users can also adjust their plans accordingly. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 13 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] why duplicate output lines in verbose tests?
Antoine Pitrou wrote: As Martin suggested in this issue's comments, a simple fix would be to wrap most methods with an instance-specific mutex. I don't know how that would affect performance. For 3.0, I think correctness is more important than speed. At this stage, we may have to live with the fact that some aspects of 3.0 are going to be slower than they are in 2.6 (the Decimal module comes to mind, and it looks like IO may be another one). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
On 2008-08-13 04:57, Guido van Rossum wrote: And there's a reason for this slow uptake of Python 2.5: as more and more servers run 64-bit OSes, the Py_ssize_t changes cause serious trouble with Python C extensions that were not updated by their authors. I'm not sure what that has to do with anything. The older releases have *worse* support for 64-bit platforms! This is one of the reasons why porting applications from 2.4 to 2.5 takes longer than e.g. moving from 2.3 to 2.4. Python 2.4 works just fine on 64-bit platforms and so do the C extensions that were written for it. Moving to 2.5 you often find that those C extensions do not support the new Py_ssize_t types and thus generate segfaults. As a result, you either have to start using a different C extension, patch the extension, stay with Python 2.4 or use a custom Python interpreter that is patched always map Py_ssize_t to int. The move from 2.5 to 2.6 will be a lot easier and uptake a lot faster. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 13 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 -> 3000 code transition?
> (*) slides: > http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf Hilarious! Seems like that would have been a riot of a session to attend. (I'm kicking myself for attending some other uninteresting talk when yours was on.) Trent. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 -> 3000 code transition?
I'm planning on re-presenting it at the local google office in the next couple of weeks. I might try and arrange for it to be recorded and put online. At the moment we seem to have a real lack of concrete information for people about the transition. If I had time (ha! HA!) I'd try to turn the slides into a series of articles. Right now, there's the What's New In Python 3.0, and the PEPs. The former isn't complete yet (obviously) and isn't all that detailed. The latter is a whole pile of text, some relevant and some not so much. Anthony On Wed, Aug 13, 2008 at 10:09 PM, Trent Nelson <[EMAIL PROTECTED]> wrote: >> (*) slides: >> http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf > > Hilarious! Seems like that would have been a riot of a session to attend. > (I'm kicking myself for attending some other uninteresting talk when yours > was on.) > >Trent. > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 -> 3000 code transition?
Last time I looked at it, the C API wasn't nailed down yet. That's why I passed over it entirely for my tutorial. The only advice I was able to give was that if your extension is just a wrapper around existing C code, you might be better off rewriting it using ctypes. That way it should work on both 2.6 and 3.0. This doesn't work for PyCXX, of course :-( On Fri, Jul 25, 2008 at 8:33 AM, Barry Scott <[EMAIL PROTECTED]> wrote: > > On Jul 21, 2008, at 22:37, Lennart Regebro wrote: > >> On Mon, Jul 21, 2008 at 20:16, Brett Cannon <[EMAIL PROTECTED]> wrote: >>> >>> But waiting until all the betas have gone out totally defeats the >>> purpose of the betas! >> >> I agree. Writing an actual *guide* can wait, but documenting the >> differences with code examples is a work that can start now, and I >> agree that it would be great if this would start now. >> >> But writing a guide might not be a good idea until we know what the >> changes are, and if the API is changing quickly now we don't. :-) > > I'm working on getting a version of PyCXX working with Python 3.0. > The lack of any docs outside of the header files is making this a slow > process. > > I think its a mistake to expect a serious beta test of extensions > when you have no guide to the changes in the C API. > > If you had a guide then diff it between releases would be a guide to > what need fixing up going from beta to beta to rc. > > Oh and I'm not going to try and make a version of PyCXX that works > on 2.x and 3.x as the changes are too fundamental. > > Barry > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/anthony%40interlink.com.au > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
M.-A. Lemburg wrote: On 2008-08-13 07:53, Martin v. Löwis wrote: Because there won't typically be sufficient testing and release infrastructure to allow arbitrary bug fixes to be committed on the branch. The buildbots are turned off, and nobody tests the release candidate, no Windows binaries are provided - thus, chances are very high that a bug fix release for some very old branch will be *worse* than the previous release, rather than better. Second, I don't think this is true. People using those patch level releases will test and report bugs if they are introduced by such backports. They might be using releases, but they are *not* using the subversion maintenance branches. Do you know anybody who regularly checks out the 2.4 maintenance branch and tests it? So at best, people will only report bugs *after* the release was made, meaning that there is a realistic chance that the release itself breaks things. I think that's an overly pessimistic view. There's always a chance of breaking things when patching anything - whether that's a security fix or a fix for a bug that's hard to work around in an application using Python. Note that those fixes will usually be backports from a more recent release, so even if they don't receive enough direct testing on the older branch before the release is cut, they will get their share of testing either in the context of the more recent branch. I'm not a great believer in "indirect testing" of this kind. As for using the releases themselves: there have been 80462 downloads of 2.4.5 since it was released in March, as compared to 517325 downloads of the 2.5.2 MSI in July alone. So I'm skeptical that many people do actually use the 2.4.5 release. It's difficult to use such download numbers as hint for the number of deployed installations. 2.4.5 was not released as binary, so interested parties had to compile that version by themselves and those installations don't show up in your statistics. I'm sure that if we had released binaries as well, the number would have looked different, esp. if you only look at the Windows binaries. Besides, developers backporting such changes are diligent enough to test their changes - they will usually have a reason for applying the extra effort to backport. My problem is that this backporting is not systematic. It's arbitrary whether patches get backported or not. Part of the problem is that it is/was also unclear whether there ever will be another release made out of 2.4. That's a valid point, but does this really warrant backing out changes that have already been applied ? Isn't it better to get at least some bugs fixed rather than to not fix them at all ? No, given that (in teh USA in 1999, anyway) there's a 7% chance that a bugfix will inject a new problem. That chance goes up when testing is minimal - testing of later releases doesn't validate untested amendments to earlier releases. When 2.4.4 was released, Anthony announced, in http://mail.python.org/pipermail/python-dev/2006-October/069326.html "This will be the last planned release in the Python 2.4 series" So anybody committing to the 2.4 branch after that should have expected that the patches will never get released. Perhaps we should just document the maintenance of Python releases more clearly and also plan for a final bug fix release 3 years after the initial branch release. That way developers and users can also adjust their plans accordingly. As always the problem is getting someone to do this not insignificant amount of work. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 -> 3000 code transition?
On Wed, 2008-08-13 at 22:20 +1000, Anthony Baxter wrote: > Last time I looked at it, the C API wasn't nailed down yet. That's why > I passed over it entirely for my tutorial. The only advice I was able > to give was that if your extension is just a wrapper around existing C > code, you might be better off rewriting it using ctypes. Given that ctypes doesn't work on a number of popular architectures, including x86_64 (the last time I looked), I'd hardly call that "better off". :-( ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
On 2008-08-13 15:20, Steve Holden wrote: M.-A. Lemburg wrote: Perhaps we should just document the maintenance of Python releases more clearly and also plan for a final bug fix release 3 years after the initial branch release. That way developers and users can also adjust their plans accordingly. As always the problem is getting someone to do this not insignificant amount of work. We'd just have to add a section to the release schedule PEP: Release Maintenance Bug fix releases will be made available until September 19, 2009. The following bug fix releases have been posted: 2.5.1: February 22, 2008 2.5.2: April 18, 2007 Security fix releases will continue to be made available as necessary until September 19, 2011. No further updates will be posted after that date. The following security fix releases have been posted: No security fix releases have been released. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 13 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
Why not migrate support for older releases to interested parties outside of the regular developer team? Presuming there is someone out there with the interest in maintaining, say, Python 2.2, they could take over the entire responsibility for making releases, continuing to use the Subversion repository if they like, releasing on their own schedule, in the formats they deem appropriate. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 -> 3000 code transition?
>> (*) slides: >> http://www.interlink.com.au/anthony/tech/talks/OSCON2008/porting3.pdf Trent> Hilarious! Seems like that would have been a riot of a session Trent> to attend. (I'm kicking myself for attending some other Trent> uninteresting talk when yours was on.) Indeed. Slide 155 is a typo, right? Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 -> 3000 code transition?
Le Wednesday 13 August 2008 15:27:42 Hrvoje Nikšić, vous avez écrit : > Given that ctypes doesn't work on a number of popular architectures, > including x86_64 (the last time I looked), I'd hardly call that "better > off". :-( I wrote a debugger based on ptrace using ctypes: http://fusil.hachoir.org/trac/wiki/python-ptrace The debugger works well on: - Ubuntu Gutsy, i386 - Debian Etch, x86_64 <= yes, it works well - Debian Etch, ppc32 - FreeBSD 6.2 and 7.0, i386 <= yes, ctypes runs fine on FreeBSD too (so Python 2.4 with ctypes the external ctypes module and Python 2.5 with included ctypes) I have no other computer to test other CPUs :) ctypes allows to write code working on CPython 2.4, 2.5, 2.6 and 3.0 (with 2to3), but also on PyPy! Jython plans also to support ctypes. So, please, retry ctypes ;-) -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest Suggestions
Barry Warsaw python.org> writes: > The goal > should be to produce something like a unittest-ng, distribute it via > the Cheeseshop, and gather consensus around it for possible inclusion > in Python 2.7/3.1. There is already unittest, nose, py.test, trial... perhaps others I don't know of. I fear writing yet another testing framework from the ground-up will lead to more bikeshedding and less focussed discussion (see some testing-in-python threads for an example :-)). nose itself is not a completely independent piece of work but "a discovery-based unittest extension" (although a very big extension!). For that reason, Michael Foord's suggestion to gradually modernize and improve the stdlib unittest sounds reasonable to me: it allows to be more focussed, keep backwards compatibility, and also to decide and implement changes piecewise - avoiding the blank sheet effect where people all push for wild ideas and radically new concepts (tm). (however, nose is LGPL-licensed so it would not be suitable for direct reuse of large chunks of code in the stdlib, unless the authors agree for a relicensing) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest Suggestions
On Wed, 13 Aug 2008 15:35:15 + (UTC), Antoine Pitrou <[EMAIL PROTECTED]> wrote: Barry Warsaw python.org> writes: The goal should be to produce something like a unittest-ng, distribute it via the Cheeseshop, and gather consensus around it for possible inclusion in Python 2.7/3.1. There is already unittest, nose, py.test, trial... perhaps others I don't know of. I fear writing yet another testing framework from the ground-up will lead to more bikeshedding and less focussed discussion (see some testing-in-python threads for an example :-)). nose itself is not a completely independent piece of work but "a discovery-based unittest extension" (although a very big extension!). For that reason, Michael Foord's suggestion to gradually modernize and improve the stdlib unittest sounds reasonable to me: it allows to be more focussed, keep backwards compatibility, and also to decide and implement changes piecewise - avoiding the blank sheet effect where people all push for wild ideas and radically new concepts (tm). (however, nose is LGPL-licensed so it would not be suitable for direct reuse of large chunks of code in the stdlib, unless the authors agree for a relicensing) trial is also an extension of the stdlib unittest module (less and less over time as more and more stdlib unittest changes break it). Incremental improvements with backwards compatibility are a great thing. I very strongly encourage that course of action. It has already happened a number of times in this thread that some proposed functionality already exists in some third-party unittest extension and could easily be moved into the stdlib unittest module. That's a good thing: it shows that the functionality is actually valuable and it makes it easy to include, since it's already implemented. For what it's worth, trial is MIT licensed; anyone should feel free to grab any part of it they like for any purpose. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] pybsddb 4.7.3pre1: Compatibility with Python 3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. Sorry for spamming several mailing list. After many hours of hard work, I'm proud to present a preview of pybsddb 4.7.3, able to compile and work under Python 2.3, 2.4, 2.5, 2.6b2 and 3.0b2. You can try it out downloading it directly from my repository: ~ svn co -r 597 svn://svn.argo.es/jcea/pybsddb/trunk \ ~ pybsddb-4.7.3pre1 Please, DO NOT download any other revision, since I can make changes anytime, breaking things. To exercise the testsuite (currently, 304 tests, if you are running the more recent Berkeley DB release (4.7.25)), do: ~ python2.3 test.py -bv ~ python2.4 test.py -bv ~ python2.5 test.py -bv ~ python2.6 test.py -bv ~ python3.0 test.py -bv This will compile the code and run the testsuite for each supported python release. Of course you need to have Berkeley DB installed, better if you have 4.6 (fully patched, the original release was very buggy) or the last 4.7.25 release (rock solid). You can install the code using the usual "python setup.py install". BEWARE, nevertheless; this code is not ready for production use, especially under Python 3.0. But, please, test your code with this preview. Test it as hard as you can. Current code has several ugly hacks (like some abuse of "hasattr" to avoid selected automatic 2to3 conversion), but it works and it will be improved in the future. Please, report any issue, incompatibility or improvement you can see. I plan to release pybsddb 4.7.3 in mid-september, ready to be delivered bundled in Python 2.6/3.0 (to be released early in october). I'll be on summer holidays, 100% offline, until early september. I will read your comments as soon as possible. Thanks for your time!. Homepage: http://www.jcea.es/programacion/pybsddb.htm http://www.jcea.es/programacion/pybsddb.htm#bsddb-4.7.3 http://www.jcea.es/programacion/pybsddb_doc/preview/ CHANGES SINCE 4.7.2: """ ~ * "private" is a keyword in C++. (Duncan Grisby) ~ * setup.py should install "bsddb.h". (Duncan Grisby) ~ * "DB_remove" memory corruption & crash. (Duncan Grisby) ~ * Under Python 3.0, you can't use string keys/values, but ~bytes ones. Print the right error message. ~ * "DB.has_key()" allowed transactions as a positional parameter. ~We allow, now, transactions as a keyword parameter also, as ~documented. ~ * Correct "DB.associate()" parameter order in the documentation. ~ * "DB.append()" recognizes "txn" both as a positional and a ~keyword parameter. ~ * Small fix in "dbshelve" for compatibility with Python 3.0. ~ * A lot of changes in "dbtables" for compatibility with Python 3.0. ~ * Huge work making the testsuite compatible with Python 3.0. ~ * In some cases the C module returned Unicode strings under ~Python 3.0. It should return "bytes", ALWAYS. Solved. """ NOTES ABOUT PYTHON 3.0: The most visible change in Python 3.0, related to this library, is that Python 2.x strings are replaced by unicode strings and "bytes" objects. Under Python 3.0, pybsddb always consumes and produces "bytes" objects. Unicode strings are rejected. To easy testsuite porting, I've defined some minimal proxy/adapter objects to facade unicode strings from/to "bytes". So, current testsuite works for every supported python release, with the minimal conditional code. These adapter objects ARE NOT INTENTED to be used in production. If you are developing for Python 3.0, just use the right approach: use the native "bytes" objects. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBSKMWY5lgi5GaxT1NAQL64gP/flHcMi3PIMuy2iiMZftYZ9GLVFLztxxD FZBivMJj/n3+B6tQ4PK9FZwYvelE4lgTPuC/Lv94SJi8xW3CxtLyjoUcj7Pobf3t 8cV6jXdcczQbYa8/4+kptQyHhr/lNnQD9vZ7Do1+D8Zdoz/vUM6yXKoKQnAiDcfQ 0qmlY+15SgA= =RNRk -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
> It's difficult to use such download numbers as hint for the number > of deployed installations. 2.4.5 was not released as binary, so > interested parties had to compile that version by themselves and > those installations don't show up in your statistics. You mean, they installed it *without* downloading it? How did they do that? > I'm sure that if we had released binaries as well, the number would > have looked different, esp. if you only look at the Windows binaries. See, that's exactly the problem. We don't have the resources to provide Windows binaries. So even if the release contained regular bug fixes, I *still* would not have released Windows binaries. > That's a valid point, but does this really warrant backing out > changes that have already been applied ? Isn't it better to get > at least some bugs fixed rather than to not fix them at all ? Yes. Otherwise, neither developers nor users have a clear guideline what to expect. > Perhaps we should just document the maintenance of Python releases > more clearly and also plan for a final bug fix release 3 years after > the initial branch release. That way developers and users can also > adjust their plans accordingly. There was clear documentation. It said "2.4 is done, finished, closed, over with, not maintained anymore". We had been doing that for many releases in the past. Now, you and me, we both want to change the policy. I want to change to provide security releases for a period of five years, and I think this is feasible with the resources that we have. You just suggested to provide bug fix releases for three years, and I think that is not feasible. In addition, it still would mean that we should not have done a bug fix release in 2008 (as 2.4.5 was released in March 2008); instead, the last bug fix release should have been made in November 2007. Nobody (including yourself) stepped forward at that time and offered to roll a release. 2.4 was release on November 30, 2004. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest Suggestions
On Wed, 13 Aug 2008, Antoine Pitrou wrote: [...] nose itself is not a completely independent piece of work but "a discovery-based unittest extension" (although a very big extension!). For that reason, Michael Foord's suggestion to gradually modernize and improve the stdlib unittest sounds reasonable to me: it allows to be more focussed, keep backwards compatibility, and also to decide and implement changes piecewise - avoiding the blank sheet effect where people all push for wild ideas and radically new concepts (tm). +1 (speaking as somebody who has worked on nose a bit) John ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
On 2008-08-13 22:32, Martin v. Löwis wrote: It's difficult to use such download numbers as hint for the number of deployed installations. 2.4.5 was not released as binary, so interested parties had to compile that version by themselves and those installations don't show up in your statistics. You mean, they installed it *without* downloading it? How did they do that? What I was trying to say is that you only see a single source download, which someone then takes, compiles and possibly redistributed or integrates into a product. As a result a single download can easily map to quite a few installations - and that's what we should base our assumptions on. I'm sure that if we had released binaries as well, the number would have looked different, esp. if you only look at the Windows binaries. See, that's exactly the problem. We don't have the resources to provide Windows binaries. So even if the release contained regular bug fixes, I *still* would not have released Windows binaries. I was just suggesting that the number of downloads would have been higher had you released Windows binaries as well. We see that all the time with the eGenix products. Anyway, that's just statistics :-) That's a valid point, but does this really warrant backing out changes that have already been applied ? Isn't it better to get at least some bugs fixed rather than to not fix them at all ? Yes. Otherwise, neither developers nor users have a clear guideline what to expect. I disagree on that, but I'm fine with such a plan if it's documented well in advance. Perhaps we should just document the maintenance of Python releases more clearly and also plan for a final bug fix release 3 years after the initial branch release. That way developers and users can also adjust their plans accordingly. There was clear documentation. It said "2.4 is done, finished, closed, over with, not maintained anymore". We had been doing that for many releases in the past. Right, but that documentation was only available after the release manager decided to stop creating releases for that branch - ie. around the time that final release was cut. In order to plan for the end of lifetime of a software product, you need this information well upfront - for both the developers (so that they can get fixes in before the end-of-lifetime) and users (who will then have to plan to upgrade their installations and products relying on Python). Now, you and me, we both want to change the policy. I want to change to provide security releases for a period of five years, and I think this is feasible with the resources that we have. You just suggested to provide bug fix releases for three years, and I think that is not feasible. Actually, I was suggesting to have bug fix releases for 3 years and security fixes for another 2 years (ie. 5 years lifetime in total). In addition, it still would mean that we should not have done a bug fix release in 2008 (as 2.4.5 was released in March 2008); instead, the last bug fix release should have been made in November 2007. Nobody (including yourself) stepped forward at that time and offered to roll a release. 2.4 was release on November 30, 2004. I don't want this written in stone, but there should be a pre-defined roadmap for the whole lifetime Python release branch - from start to end. Please note that a policy is really just that: a guideline for everyone to follow. It doesn't restrict us in maintaining a release for more than the originally intended 3/5 years phases or creating a bug fix release after the initial 3 years. However, it should be seen as guideline for the minimum amount of time a release is being maintained - for everyone to see early (ie. in the Python release PEP) and use as basis for making decisions on which release to take as basis for a software project. Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 13 2008) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
> What I was trying to say is that you only see a single source download, > which someone then takes, compiles and possibly redistributed or > integrates into a product. As a result a single download can > easily map to quite a few installations - and that's what we should > base our assumptions on. The same is true for any later release, too. A single release of Python 2.5.2 will result in many Debian installations, for example. Still, the *ratio* of the downloads is quite informative, since the same factors apply to both branches. In the specific case, we know that Debian provides 2.5.2, but not 2.4.5, as they avoid integrating newer releases out of fear for new features, and selectively only pick the security patches. So I can cite at least one large multiplicator product which *doesn't* want new maintenance branch releases, but wants explicit identification of security patches only. I recall people from Redhat saying the same thing. >> There was clear documentation. It said "2.4 is done, finished, closed, >> over with, not maintained anymore". We had been doing that for many >> releases in the past. > > Right, but that documentation was only available after the release > manager decided to stop creating releases for that branch - ie. > around the time that final release was cut. No, it was discussed months in advance, and had been followed at least for the 2.3 release (the final 2.2 release occurred even before 2.3). 2.3.5 states, on its web page, that it is the final release of 2.3. > In order to plan for the end of lifetime of a software product, > you need this information well upfront - for both the developers > (so that they can get fixes in before the end-of-lifetime) and > users (who will then have to plan to upgrade their installations > and products relying on Python). Right. Therefore, I circulated a PEP proposing such a strategy in May 2007. > I don't want this written in stone, but there should be a pre-defined > roadmap for the whole lifetime Python release branch - from start to > end. I agree with that. Unfortunately, my PEP didn't get much feedback at that time. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 13, 2008, at 1:53 AM, Martin v. Löwis wrote: Because there won't typically be sufficient testing and release infrastructure to allow arbitrary bug fixes to be committed on the branch. The buildbots are turned off, and nobody tests the release candidate, no Windows binaries are provided - thus, chances are very high that a bug fix release for some very old branch will be *worse* than the previous release, rather than better. Second, I don't think this is true. People using those patch level releases will test and report bugs if they are introduced by such backports. They might be using releases, but they are *not* using the subversion maintenance branches. Do you know anybody who regularly checks out the 2.4 maintenance branch and tests it? So at best, people will only report bugs *after* the release was made, meaning that there is a realistic chance that the release itself breaks things. Sure, but this is just as true for security fixes. The only thing the policy buys us is fewer /possibilities/ of breakage. I'm not discounting that as worthwhile, but qualitatively, there's no difference between non-security fixes and security fixes, as far as our Q/A process goes. My problem is that this backporting is not systematic. It's arbitrary whether patches get backported or not. Part of the problem is that it is/was also unclear whether there ever will be another release made out of 2.4. When 2.4.4 was released, Anthony announced, in http://mail.python.org/pipermail/python-dev/2006-October/069326.html "This will be the last planned release in the Python 2.4 series" So anybody committing to the 2.4 branch after that should have expected that the patches will never get released. There's a difference between never being released, and unavailable in the source repository. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKNiEXEjvBPtnXfVAQIQgAP6A84mpv0JUkP4Z904TzoYDuqb3OtCNBMc wo+VGw00p9JJ0f4lWRmXSkimtLNe1xoOj0/qhYXBa64P7ti3oa9Wo4VHCK/N0IcW p8vXvhMG9sIhYrGb2cWDc4d/UA0kQqBPp3srtXwEumoWQbScH0zJHM7llX10unJ1 UfTST6Tof/s= =ilvh -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 13, 2008, at 10:29 AM, [EMAIL PROTECTED] wrote: Why not migrate support for older releases to interested parties outside of the regular developer team? Presuming there is someone out there with the interest in maintaining, say, Python 2.2, they could take over the entire responsibility for making releases, continuing to use the Subversion repository if they like, releasing on their own schedule, in the formats they deem appropriate. This I agree with. If nobody's motivated to do the work, then problem solved, it doesn't get done. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKNjW3EjvBPtnXfVAQLCLwP/QEFeXZstWcEuLbicMuqipREQsruTJW9v SJURMYCZBdfkgiTm3cr2MVK9e/FpX7FUvhCKlAOpyAFOWM3FFiv/J+wBRNHcli2p NHYbG8scmUHwVZ1oL1pWr7NLgECh0DsXBTWWubRyR3XqG1bdnk+B0wKuzcxNOH5Y McLahXhN56g= =m7SB -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
> There's a difference between never being released, and unavailable in > the source repository. So would you have preferred if I had forked another branch that still contained these patches? Such branch can still be added now. Nothing that gets added to the source repository ever becomes unavailable. Re-adding them is fairly easy: they are all in r61179. Going forward, the question would then be if these patches will ever get released. So there could be two branches, one that people can commit arbitrary bug fixes to (which will never be released), and one that gets security patches (which will get released for five years). Of course, I would personally find it fairly confusing to have people commit patches that are explicitly will not be released, and still aren't experimental or private-use. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
On Wed, Aug 13, 2008 at 4:11 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> There's a difference between never being released, and unavailable in >> the source repository. > > So would you have preferred if I had forked another branch that still > contained these patches? Such branch can still be added now. Nothing > that gets added to the source repository ever becomes unavailable. > Re-adding them is fairly easy: they are all in r61179. > > Going forward, the question would then be if these patches will ever > get released. So there could be two branches, one that people can commit > arbitrary bug fixes to (which will never be released), and one that > gets security patches (which will get released for five years). > > Of course, I would personally find it fairly confusing to have people > commit patches that are explicitly will not be released, and still > aren't experimental or private-use. > And toss in having the potential 2.6/2.7/3.0/3.1 branches all at once and that makes having separate security and bug fix branches just not work. To toss in my opinion (which shouldn't count for too much since I have yet to cut a release), I am mostly with Martin on this one. We currently keep one version back running on the buildbots so we at least have some inkling of what patches do so we can provide some level of quality control on releases (even though we have some red stable buildbots for 2.5 right now). But without running buildbots on the code who knows what a change will do on various platforms. And who wants to deal with a bug report on 2.4 at this point? Now I would have said that someone could just cut a release if they want and people can just not be expected to backport if they don't feel like it. But then what about when we do fix security issues? If someone does a backport of a security fix but can't run the test suite because that version of Python has not been tested on their OS or buildbot, then that stonewalls their work. I would not want to potentially see this happen. Basically my opinion boils down to a version should be maintained as long as we have the infrastructure to be testing it regularly on the buildbots (or whatever the equivalent is for our integrated testing). As of right now that means the current version and the trunk. If we actually manage to get the manpower and machines to maintain more, then we can consider maintaining versions longer. But as of right now we don't not have the volunteers to do this and so I don't think we should be considering doing more than what we are doing now. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Frequently-requested additional features for the `unittest` module
Ben Finney wrote: Michael Foord <[EMAIL PROTECTED]> writes: The full list of changes proposed […] and not shot down was something like: […] assertLessThan assertGreaterThan assertLessThanOrEquals assertGreaterThanOrEquals […] "Brett Cannon" <[EMAIL PROTECTED]> writes: Is any of this really necessary? Isn't this the equivalent of ``assert_(a < b)``? It seems like the only thing you get out of this is a nicer error message, but ``assert_(a < b, 'not %r <= %s' % (a, b))`` is not that complex. And do these cases really come up that often? I would want to see some numbers showing that these are really necessary (in both usage and people even specifying an error message in the first place). Though I'm the champion of this PEP, I'll have to refer to Michael Foord for his reasoning (or reference to others' reasoning) on this. My reasoning goes something like this: self.assertLessThan(abs(self.base.method(parm1, parm2) - self.base.nominal), 2.54, 'Within an inch') vs. distance = self.base.method(parm1, parm2) deviation = self.base.method(parm1, parm2) - self.base.nominal self.assert_(abs(deviation) < 2.54, '%s is %s out of spec (more ' 'than an inch)' % (distance, deviation) It is not so much the assertion on values in variables, as it is assertions on results of calculations. Unfortunately, my tendency would be to forgo the "within an inch" over extracting the values into locals for the purpose of the test; the tests I'm writing currently focus on the manipulation of hardware for the reader, not on the extraction of data for the purpose of testing. Some of the longer sections are already nearly a couple of pages long; that's how much code it takes to do a coherent operation on this particular hardware. I hate that I am using 2 pages now (half a page per is what I'd prefer), and I'm not willing to bloat the operation with more code. As a result, I implemented my own versions of these asserts (Le, Lt, ...) a year or so ago, and still find them so useful that I'll re-implement them where- ever I am working without similar tests available. --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 13, 2008, at 7:11 PM, Martin v. Löwis wrote: There's a difference between never being released, and unavailable in the source repository. So would you have preferred if I had forked another branch that still contained these patches? Such branch can still be added now. Nothing that gets added to the source repository ever becomes unavailable. Re-adding them is fairly easy: they are all in r61179. Sure, but nobody's going to dig through commit messages to dig out those patches. I'm not sure what I would have preferred. Really, I was mostly fine with the decision to do as we did. But if we stick with the policy you propose (which I'm not sure is completely nailed down yet), then I will be sure not to waste my time on closed releases next time. Going forward, the question would then be if these patches will ever get released. So there could be two branches, one that people can commit arbitrary bug fixes to (which will never be released), and one that gets security patches (which will get released for five years). Of course, I would personally find it fairly confusing to have people commit patches that are explicitly will not be released, and still aren't experimental or private-use. No, I don't think we need another branch per version. I'm clearly in the minority, and I've said my peace on the subject, so I'll let it go. Moving forward, I do want to make sure we communicate to our users and developers, exactly what the policy is, with enough advanced warning for each version so that they can plan ahead and won't waste time. Ideally, we would lay this out when we plan the release. For example, let's project dates for closing 2.6 and 3.0 now, and add them to PEP 361. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSKOvzXEjvBPtnXfVAQImrAP+IZHk711jPL8GdfrFiENt0KgGD5vjjg/g kxgBsyVWi/wOonM0cFUABzSxBzfCOPd1eWtD54bs4rk32sXA+v3qtoHKylPsv/0O 8WUq4dXZ3LLn7D50WKWrJNIKTlAaxoH+OWCKK+qgaCEFhv/uKAISaeAxADh2vlzK YQmkz//7Jjs= =GTEP -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Maintaining old releases
> For example, let's project dates for closing 2.6 and 3.0 now, and add > them to PEP 361. My view is that they should be closed when 2.7 and 3.1 are released. Following another informal policy, we were going for an 18 months release cycle at some time (2.6 clearly took longer), which would mean that those branches get closed on March 1, 2010. Security releases will be available until October 1, 2013. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
