On 01/28/2014 06:50 PM, Larry Hastings wrote: > > See the recent discussion "Deprecation policy" right here in python-dev for a cogent discussion on this issue. I agree > with Raymond's view, posted on 1/25: > > * A good use for deprecations is for features that were flat-out misdesigned > and prone to error. For those, there is nothing wrong with deprecating them > right away. Once deprecated though, there doesn't need to be a rush to > actually remove it -- that just makes it harder for people with currently > working code to upgrade to newer versions of Python. > > * When I became a core developer well over a decade ago, I was a little > deprecation happy (old stuff must go, keep everything nice and clean, etc). > What I learned though is that deprecations are very hard on users and that > the purported benefits usually aren't really important. I also agree with this view. > I think the "times behaves differently when passed by name versus passed by position" behavior falls exactly into this > category, and its advice on how to handle it is sound. I don't agree with this. This is a bug. Somebody going through (for example) a code review and making minor changes so the code is more readable shouldn't have to be afraid that [inserting | removing] the keyword in the function call is going to *drastically* [1] change the behavior. I understand the need for a cycle of deprecation [2], but not fixing it in 3.5 is folly. -- ~Ethan~ [1] or change the behavior *at all*, for that matter [2] speaking of deprecations, are all the 3.1, 3.2, etc., etc., deprecations being added to 2.7?
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