3.0.1 possibilities
Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues. Thoughts? [1] http://bugs.python.org/1717 [2] http://bugs.python.org/4533 [3] http://bugs.python.org/4561 [4] http://bugs.python.org/4565 -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."
Strong +1 Are the RMs on board? ----- Original Message ----- From: "Benjamin Peterson" <musiccomposition@gmail.com> To: <python-dev@python.org> Sent: Saturday, December 06, 2008 3:18 PM Subject: [Python-Dev] 3.0.1 possibilities
Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues. Thoughts?
[1] http://bugs.python.org/1717 [2] http://bugs.python.org/4533 [3] http://bugs.python.org/4561 [4] http://bugs.python.org/4565
-- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." _______________________________________________ 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/python%40rcn.com
+1 On Sat, Dec 6, 2008 at 3:18 PM, Benjamin Peterson <musiccomposition@gmail.com> wrote:
Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues. Thoughts?
[1] http://bugs.python.org/1717 [2] http://bugs.python.org/4533 [3] http://bugs.python.org/4561 [4] http://bugs.python.org/4565
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 6, 2008, at 6:25 PM, Guido van Rossum wrote:
On Sat, Dec 6, 2008 at 3:18 PM, Benjamin Peterson <musiccomposition@gmail.com> wrote:
Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues. Thoughts?
[1] http://bugs.python.org/1717 [2] http://bugs.python.org/4533 [3] http://bugs.python.org/4561 [4] http://bugs.python.org/4565
I've set the priority on all these to release blockers, but I have my reservations about 4561 and 4565. Resolution of those seem like more than a week or so away. If we want to do a bug fix release for 3.0.1, I'd like to do it no later than the 19th. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSTsNtXEjvBPtnXfVAQKI4AP8CNQEEb2KuN8cvd+t6YK39jFPxEo8j/YV 022zAWX3nNgj/R88C7OwoP6nYLx+zz4D3USj65OZN4NS9W9tJYKs+Lv6CnjIJi2X cVceihcJHVYbyx8r14mYt6VjSmpTuNBD8uPZGv23WLZJZ5pNpWeuEMqI6XR27bY2 NYxbwSEUQpw= =3wZN -----END PGP SIGNATURE-----
On Sat, Dec 6, 2008 at 15:41, Barry Warsaw <barry@python.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Dec 6, 2008, at 6:25 PM, Guido van Rossum wrote:
On Sat, Dec 6, 2008 at 3:18 PM, Benjamin Peterson <musiccomposition@gmail.com> wrote:
Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues. Thoughts?
[1] http://bugs.python.org/1717 [2] http://bugs.python.org/4533 [3] http://bugs.python.org/4561 [4] http://bugs.python.org/4565
I've set the priority on all these to release blockers, but I have my reservations about 4561 and 4565. Resolution of those seem like more than a week or so away.
If we want to do a bug fix release for 3.0.1, I'd like to do it no later than the 19th.
+1 just to get rid of cmp(). And if io speedups can happen, great, but they can also wait for 3.0.2. -Brett
Brett Cannon wrote:
On Sat, Dec 6, 2008 at 15:41, Barry Warsaw <barry@python.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Dec 6, 2008, at 6:25 PM, Guido van Rossum wrote:
On Sat, Dec 6, 2008 at 3:18 PM, Benjamin Peterson <musiccomposition@gmail.com> wrote:
Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues. Thoughts?
[1] http://bugs.python.org/1717 [2] http://bugs.python.org/4533 [3] http://bugs.python.org/4561 [4] http://bugs.python.org/4565 I've set the priority on all these to release blockers, but I have my reservations about 4561 and 4565. Resolution of those seem like more than a week or so away.
If we want to do a bug fix release for 3.0.1, I'd like to do it no later than the 19th.
+1 just to get rid of cmp(). And if io speedups can happen, great, but they can also wait for 3.0.2.
A point release just to remove a function whose withdrawal has been advertised as a 3.0 change hardly seems worth the substantial effort of cutting a release. If cmp() shouldn't have been in 3.0 and was then there's surely no problem about removing it later as promised: anyone who uses it in 3.0 code shouldn't be. If it doesn't have to wait for a major release then is there any real need to cut the minor release immediately? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
On Sun, Dec 7, 2008 at 5:38 AM, Steve Holden <steve@holdenweb.com> wrote:
A point release just to remove a function whose withdrawal has been advertised as a 3.0 change hardly seems worth the substantial effort of cutting a release. If cmp() shouldn't have been in 3.0 and was then there's surely no problem about removing it later as promised: anyone who uses it in 3.0 code shouldn't be.
If it doesn't have to wait for a major release then is there any real need to cut the minor release immediately?
Well, since 2to3 doesn't remove cmp, and it actually works, it's likely that people will be accidentally depending on it in code converted from 2.x. In the past, where there was a discrepancy between docs and code, we've often ruled in favor of the code using arguments like "it always worked like this so we'll break working code if we change it now". There's clearly an argument of timeliness there, which is why we'd like to get this fixed ASAP. The alternative, which nobody likes, would be to keep it around, deprecate it in 3.1, and remove it in 3.2 or 3.3. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Martin v. Löwis wrote:
I think it is still timely when fixed in January or February. In fact, releasing it still in December might not be possible, due to the limited time available.
The cmp() / PyObject_Compare() removal patch is almost done. With some help I can finish it until Tuesday evening. We can have another release by Monday Dec 15th. Python 3.0.0 has some defects that should be fixed before people are spending their Xmas holidays with 3.0. The defects include * cmp(), PyObject_Compare() and frieds * global/nonlocal shortcuts (global x = 0) aren't working * unnecessary slowdown of read() due slow buffer resizing. An early 3.0.1 release makes it possible to sync 2.6 and 3.0 relases again. If we release it now we can have an combined release of 2.6.2 and 3.0.2 in two months from now. Two months are quite some time to fix the performance issue of the new IO library. If Guido and Barry are fine with a lax policy on performance fixes we can integrate more tweaks. I believe performances patches were considered as features in the past. For this reason they weren't allowed for minor releases. Mark's work on long integer optimizations and json speedup are good candidates. Christian
On Sun, Dec 7, 2008 at 6:05 PM, Christian Heimes <lists@cheimes.de> wrote:
Martin v. Löwis wrote:
I think it is still timely when fixed in January or February. In fact, releasing it still in December might not be possible, due to the limited time available.
The cmp() / PyObject_Compare() removal patch is almost done. With some help I can finish it until Tuesday evening. We can have another release by Monday Dec 15th. Python 3.0.0 has some defects that should be fixed before people are spending their Xmas holidays with 3.0. The defects include
* cmp(), PyObject_Compare() and frieds * global/nonlocal shortcuts (global x = 0) aren't working
I have a patch for this [1], but I don't think this should be considered a release blocker or even backported to 3.0. It's merely a convenience feature and doesn't inhibit the usefulness of the PEP in any way.
* unnecessary slowdown of read() due slow buffer resizing.
-- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."
Benjamin Peterson wrote:
I have a patch for this [1], but I don't think this should be considered a release blocker or even backported to 3.0. It's merely a convenience feature and doesn't inhibit the usefulness of the PEP in any way.
Amaury said: An issue was already filed about this: http://bugs.python.org/issue4199 It should be ready for inclusion in 3.0.1. I'm +0 for the patch. Given the nature of Python 3.0 I'm fine with getting it right. Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 7, 2008, at 7:05 PM, Christian Heimes wrote:
Martin v. Löwis wrote:
I think it is still timely when fixed in January or February. In fact, releasing it still in December might not be possible, due to the limited time available.
The cmp() / PyObject_Compare() removal patch is almost done. With some help I can finish it until Tuesday evening. We can have another release by Monday Dec 15th. Python 3.0.0 has some defects that should be fixed before people are spending their Xmas holidays with 3.0. The defects include
* cmp(), PyObject_Compare() and frieds * global/nonlocal shortcuts (global x = 0) aren't working * unnecessary slowdown of read() due slow buffer resizing.
An early 3.0.1 release makes it possible to sync 2.6 and 3.0 relases again. If we release it now we can have an combined release of 2.6.2 and 3.0.2 in two months from now. Two months are quite some time to fix the performance issue of the new IO library.
If Guido and Barry are fine with a lax policy on performance fixes we can integrate more tweaks. I believe performances patches were considered as features in the past. For this reason they weren't allowed for minor releases. Mark's work on long integer optimizations and json speedup are good candidates.
I'm personally okay with performance fixes in point releases, as long it doesn't change API or add additional features. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSTxv5XEjvBPtnXfVAQIu6AQAkxyGwhapcREx5/E3yHUf8lWvM4lh/FdR AfHwwp7hs+yX8rR05CWAUfllY9dHcHKHvBCwTCgfuIrc4GJWbJHcx9/b19GTpzre 7fcikjQ0sk6zUq85DiJah7qL5AkA6Jmiby+rol7iudHlmQO/+6F6+aeL+vSKG8IC vYbLILAFapI= =ScYg -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 7, 2008, at 7:56 PM, Christian Heimes wrote:
Barry Warsaw wrote:
I'm personally okay with performance fixes in point releases, as long it doesn't change API or add additional features.
Does your okay include or exclude new internal APIs like new helper functions or a new C modules?
I /personally/ don't have a problem with that, but we need consensus before that becomes policy. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBST0c7nEjvBPtnXfVAQJvQwQAjrCuivCuLT3HNq6n5VvUKVkxto5wyBzW ka9YuFoBCVRDt7Z7Sn59UeLGVgrsL9Zw2rSra4cXE/1QaUzpxJlaFpafWVJilCPh +hv6/t6ky0Ww0FsEv+56SRHOVRlfqgNMIbmDXemf40Oo/IYxqNL5HP59NeIvk0oa u3Mmc7qsP1k= =ZK8M -----END PGP SIGNATURE-----
On Mon, Dec 8, 2008 at 05:11, Barry Warsaw <barry@python.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Dec 7, 2008, at 7:56 PM, Christian Heimes wrote:
Barry Warsaw wrote:
I'm personally okay with performance fixes in point releases, as long it doesn't change API or add additional features.
Does your okay include or exclude new internal APIs like new helper functions or a new C modules?
I /personally/ don't have a problem with that, but we need consensus before that becomes policy.
Internal as in just for us I am fine with, but not nothing publicly available. As for new C modules, I am fine with that as well as long as they add no new build dependencies. -Brett
Brett Cannon wrote:
On Mon, Dec 8, 2008 at 05:11, Barry Warsaw <barry@python.org> wrote:
Barry Warsaw wrote:
I'm personally okay with performance fixes in point releases, as long it doesn't change API or add additional features. Does your okay include or exclude new internal APIs like new helper functions or a new C modules? I /personally/ don't have a problem with that, but we need consensus before
On Dec 7, 2008, at 7:56 PM, Christian Heimes wrote: that becomes policy. Internal as in just for us I am fine with, but not nothing publicly available.
Where would adding a (undocumented) get_filename() method to ZipImporter objects for the benefit of the -m switch fit then? There are a few things which don't always work properly because runpy doesn't currently know how to set __file__ properly when the module comes a zipfile. Although now that I think about it, I could actually fix that "the right way" (with a documented get_filename() method on ZipImporter) for 2.7 and 3.1, while using a runpy internal workaround specifically for ZipImporter instances in the maintenance branches... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Antoine Pitrou wrote:
Nick Coghlan <ncoghlan <at> gmail.com> writes:
Where would adding a (undocumented) get_filename() method to ZipImporter objects for the benefit of the -m switch fit then?
Why not call it _get_filename() in 3.0 and get_filename() in 3.1?
Actually, since it should only be a fairly trivial couple of lines of code, I think I'm going to put it in the runpy._get_filename() helper function in the maintenance branches and only move it over to ZipImporter on the trunk and the py3k branch. That way it's completely unambiguous that this is just a bug fix for runpy rather than a new feature for ZipImporter. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 8, 2008, at 3:39 PM, Antoine Pitrou wrote:
Nick Coghlan <ncoghlan <at> gmail.com> writes:
Where would adding a (undocumented) get_filename() method to ZipImporter objects for the benefit of the -m switch fit then?
Why not call it _get_filename() in 3.0 and get_filename() in 3.1?
+1 - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBST2LKXEjvBPtnXfVAQJZzAP/avX4YgpBSmOAh6Zc2TZEnsllRz6CRa86 bEPCWF1an7H9zzDl6gS5ZjbstXoEPf0Irr+W6BTSLVnRT/G7rFgw5q/QlG2yqvCP dgOCT1Vr3PXgXouNkGaBFI5L/Aw2fuDadWUpGeA3FgH3PxaAH0XAr5LcKP2SidXc v5nDim8lCxc= =k3gW -----END PGP SIGNATURE-----
Barry Warsaw wrote:
On Dec 8, 2008, at 3:39 PM, Antoine Pitrou wrote:
Nick Coghlan <ncoghlan <at> gmail.com> writes:
Where would adding a (undocumented) get_filename() method to ZipImporter objects for the benefit of the -m switch fit then?
Why not call it _get_filename() in 3.0 and get_filename() in 3.1?
+1
Well, with release manager blessing I'll go with that approach then :) Now, where are those round tuits to actually get it implemented... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
I think it is still timely when fixed in January or February. In fact, releasing it still in December might not be possible, due to the limited time available.
The cmp() / PyObject_Compare() removal patch is almost done.
I wasn't (primarily) talking about fixing this particular issue. Time needs to be made available also for the upcoming 2.4.6 and 2.5.3 releases (which should, IMO, get priority over a 3.0 bugfix release at this point)
With some help I can finish it until Tuesday evening. We can have another release by Monday Dec 15th. Python 3.0.0 has some defects that should be fixed before people are spending their Xmas holidays with 3.0. The defects include
* cmp(), PyObject_Compare() and frieds * global/nonlocal shortcuts (global x = 0) aren't working * unnecessary slowdown of read() due slow buffer resizing.
I think 3.0.1 should also address other serious bugs in 3.0, such as - various IDLE bugs with non-ASCII characters (2827, 4008, 4323, 4410) - various ways to crash Python through the buffer protocol (4583, 4509; also 4580)
An early 3.0.1 release makes it possible to sync 2.6 and 3.0 relases again.
IIUC, you want the bugfix version number to be sync'ed. I don't think that is a useful thing to have.
If Guido and Barry are fine with a lax policy on performance fixes we can integrate more tweaks. I believe performances patches were considered as features in the past. For this reason they weren't allowed for minor releases. Mark's work on long integer optimizations and json speedup are good candidates.
I don't recall such policy, and I can't see anything wrong with including performance fixes in a bug fix release. Maybe you were confusing this with whether performance fixes can be considered release-critical (which they shouldn't, IMO)? Regards, Martin
Martin v. Löwis wrote:
I wasn't (primarily) talking about fixing this particular issue. Time needs to be made available also for the upcoming 2.4.6 and 2.5.3 releases (which should, IMO, get priority over a 3.0 bugfix release at this point)
I've no opinion on the priority of the releases. Since you are responsible for the 2.4 and 2.5 releases as well as the Windows binaries, it's your choice. For the future we should find somebody to assist you with the Windows installers in order to release some pressure from you.
I think 3.0.1 should also address other serious bugs in 3.0, such as - various IDLE bugs with non-ASCII characters (2827, 4008, 4323, 4410) - various ways to crash Python through the buffer protocol (4583, 4509; also 4580)
My list wasn't complete. I'm +1 for your additions.
IIUC, you want the bugfix version number to be sync'ed. I don't think that is a useful thing to have.
Yeah. Barry also said it's a neat thing to have - but just a neat thing.
I don't recall such policy, and I can't see anything wrong with including performance fixes in a bug fix release. Maybe you were confusing this with whether performance fixes can be considered release-critical (which they shouldn't, IMO)?
Maybe I'm a confused person? :] Christian
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Dec 7, 2008, at 11:17 PM, Martin v. Löwis wrote:
I don't recall such policy, and I can't see anything wrong with including performance fixes in a bug fix release. Maybe you were confusing this with whether performance fixes can be considered release-critical (which they shouldn't, IMO)?
I agree with that. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBST0dJHEjvBPtnXfVAQIqhwQAkdJgQs8aq452mQRWGdNKLBw5Fsu1m/uV PGcYbRvfD5nzKPhRvCK42okPaUTWXOAuLHf8gvLT+LwRewmztsMVb0JZKVf1MIuT Msw60Du7jjNgjcbgd55i5mn7swQmGONB7iFfyq5htL3Bp1zQIi+Fhhi4/hZconHl BTnbqfLGz1Q= =u9GH -----END PGP SIGNATURE-----
Benjamin Peterson <musiccomposition <at> gmail.com> writes:
Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues.
The IO library needs a lot of work to make it as fast as in 2.6, one week isn't enough. I'm not sure an emergency release with the linked patches is very useful honestly.
On Sat, Dec 06, 2008, Benjamin Peterson wrote:
Since the release of 3.0, several critical issues have come to our attention. Namely, the builtin cmp function wasn't removed [1] and the new IO library proved to be (as expected) abysmally slow [2][3][4]. Christian proposed that we release 3.0.1 within the next week to patch up this critical issues. Thoughts?
Seems overly aggressive to me. These prohibit use of 3.0 in production environments; they do not prohibit development in 3.0. I think we should target early January and make it public that we are doing so. That will give more time for any additional similar bugs to get fixed at once. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan
participants (11)
-
"Martin v. Löwis" -
Aahz -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Christian Heimes -
Guido van Rossum -
Nick Coghlan -
Raymond Hettinger -
Steve Holden