On 3/12/2011 3:04 PM, Thomas Wouters wrote: > It should be fixed, yes, but breaking existing code is going to piss off > a lot of people (like me) who already have enough worries when upgrading > Python. It is apparent that there *is* code out there that relies on > this behaviour, we shouldn't break it wlily-nilly. A warning when > CPython encounters the case that will change behaviour in the next > CPython release and in other implementations is almost as good as > changing the behaviour. Every bug fix breaks code that depends on the bug. That said, we do not backport every bug fix. I think in the long run it would be good to fix at least 2.7 and 3.2, but that could be debated. Greg Price, who started the thread wanting PyPy to replicate the somewhat undefined and crazy behavior of CPython, admits "I think a strict reading of the language reference would clearly identify this as wrong behavior by CPython." http://codespeak.net/pipermail/pypy-dev/2011q1/006966.html So he can hardly complain if we fix the 'wrong behavior'. He is not a newbie: he is the one who diagnosed why CPython behaves as it does. He also knows how to fix their code: simply add to each appended class an __iter__ method just like I did, except yield the same thing as the __radd__ method appends rather than something different. With such a fix, his software would work with buggy and fixed CPython as well PyPy. He should just do that. He apparently is not the original author. Too bad *that* programmer did not recognize and report that he had discovered a bug. I doubt that too many other people have encountered it because I expect someone would have posted something. -- Terry Jan Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4