I'm extremely averse to making the Python development process any heavier than it has to be, but the complaint that PEP 318 should have been updated to the state of play before the checkin is a fair complaint. I'm not sure what the best approach here is - should we make a motherhood-and-apple-pie statement that, all things being equal, a PEP should be updated before the code it documents is checked in? Should we aim to have it done before the first release including the code? Before the first _final_ release that includes the code? My answers would be "before checkin, where possible; before first alpha/beta release, where really possible; before first final release, absolutely". Having said that, I don't think the lack of completed PEP is a reason to back out the @ syntax from CVS. If nothing else, it being present in a released alpha is giving us very real experience with the use of the feature. There's also the issue that there's a bunch of other existing PEPs describing features that aren't up to date at all. Which brings up another related point: Many PEPs contain "open issues" and the like, that are never ever backfilled. Largely this is a matter of round tuits - the PEP authors are generally drawn from a very small group of developers. How can we encourage other people to contribute to this? The obvious way (to me) is some form of Wiki annotation. I don't think we want to make the Wiki the primary copy of the document, but I think having the PEPs annotatable would be a win. -- Anthony Baxter <anthony at interlink.com.au> It's never too late to have a happy childhood.
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