| msg86122 - (view) |
Author: Christof (seesee) |
Date: 2009-04-18 16:00 |
| It seems python 2.6.2 (at least under Windows, I have not tested other platforms) does break the len function on the reversed iterator: Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> len(reversed([1,2,3])) 3 Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> len(reversed([1,2,3])) Traceback (most recent call last): File "", line 1, in TypeError: object of type 'listreverseiterator' has no len() I don't think it was meant to work but it did in Python 2.6.1 (and 2.5 as shown above). I guess it has something to do with Issue #3689 and guess __len__ was simply removed. Problem really is that Python 2.6.2 breaks backwards compatibility. |
|
|
| msg86130 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2009-04-18 18:10 |
| Raymond, this was your change in r67478 (backported to trunk in r67498). |
|
|
| msg86143 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2009-04-18 23:30 |
| Guido decided that iterators should not support len() because he wanted bool(it) to always be True. |
|
|
| msg86145 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-04-18 23:37 |
| Uh, perhaps the behaviour wasn't optimal but breaking compatibility between two bugfix releases isn't developer-friendly either. While we could keep it in trunk, it sounds like the change should be reverted in 2.6. The backport to 2.6 was done by Georg in r67569, by the way :-) |
|
|
| msg86153 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2009-04-19 01:42 |
| It's up to you guys. I had thought to change it only for Py2.7 but Guido probably considers it to be a bug, so possibly the backport was justified. |
|
|
| msg86159 - (view) |
Author: Christof (seesee) |
Date: 2009-04-19 09:37 |
| A compatibility break in a minor bugfix version is never a good idea I guess. I understand the reasoning but this change may break quite a few packages (at least it broke mine). A workaround in programs is easy but for already released and deployed versions simply not possible. A change for Python 2.7 would be at least annoying too but I guess could be justified. Just my thoughts... |
|
|
| msg86166 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-19 11:41 |
| Is there a 2.6 release imminent? I thought I saw some discussion of a 2.6.3 release, but I'm not sure what the eventual decision was. If so, perhaps this change could be quickly reverted in the release26-maint branch? |
|
|
| msg86172 - (view) |
Author: Daniel Diniz (ajaksu2) *  |
Date: 2009-04-19 15:16 |
| Setting as a release blocker so Barry can consider this for 2.6.3 (-committers seems to suggest that it'll be released soon). |
|
|
| msg86252 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2009-04-21 17:55 |
| Essentially, the only argument for reverting this is breaking compatibility with 2.6.0 and 2.6.1. But, in the process, reverting it means breaking compatibility with 2.6.2. Since the cat is already out of the bag for 2.6.2, I think the bugfix ought to be left in-place. It's too disruptive to switch back and forth during micro releases. |
|
|
| msg86255 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-21 18:19 |
| If 2.6.3 isn't imminent, I agree this change should be left in place. |
|
|
| msg87862 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-05-16 08:33 |
| Is it okay with everyone to close this as "wont fix"? (BTW, is there some reason that the Resolution field isn't allowed to have an apostrophe in it?) There's nothing we can do about 2.6.2; it appears 2.6.3 wasn't imminent, and as Raymond says it seems disruptive to switch it back now. |
|
|
| msg87868 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-05-16 09:07 |
| > Is it okay with everyone to close this as "wont fix"? (BTW, is there > some reason that the Resolution field isn't allowed to have an > apostrophe in it?) There's nothing we can do about 2.6.2; it appears > 2.6.3 wasn't imminent, and as Raymond says it seems disruptive to > switch it back now. Well, the harm is done, unfortunately, and both resolutions have analogous downsides, so we might indeed close it. |
|
|
| msg87869 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2009-05-16 09:11 |
| Oh, answering by e-mail reopened the bug for some unknown reason. |
|
|
| msg87935 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-05-16 21:20 |
| Closing. |
|
|