[Guido van Rossum] > > - There really isn't anything "broken" about the current situation; > it's just that "next" is the only method name mapped to a slot in > the type object that doesn't have leading and trailing double > underscores. I'm way behind on the email for this list, but I wanted to chime in with an idea related to this old thread. I know we want to limit the rate of language/feature changes for the business community. At the same time, this situation with iterators is proof that even the best thought out new features can still have a few blemishes that get discovered after they've been incorporated into Python proper. It's just terribly difficult to get anything "right" the very first time, and it would be nice to fix these blemishes sooner, rather than later. So perhaps we need some sort of concept of a "grace period" on brand-new features during which blemishes can be polished off, even if the polishing breaks backward compatibility. After the grace period, breaking backward compatibility becomes a higher priority. Since we are talking about backward compatibility only as it relates to the brand-new features themselves, Python-In-A-Tie folks can avoid the issue altogether by not using the new features during the grace period. Would something like this be an acceptable compromise? -- Patrick K. O'Brien Orbtech ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- Web: http://www.orbtech.com/web/pobrien/ Blog: http://www.orbtech.com/blog/pobrien/ Wiki: http://www.orbtech.com/wiki/PatrickOBrien -----------------------------------------------
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