On Thu, Jun 26, 2008 at 8:21 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: > Barry Warsaw wrote: >> >> On Jun 26, 2008, at 10:40 AM, Nick Coghlan wrote: >> >>> Well, that and the beta deadline (we have to draw the line somewhere, or >>> we'll be stuck in an eternal spiral of "just one more feature") >> >> Guido wanted to get the beta out when we did exactly so we could draw this >> line in the sand. I'd much rather people be spending time getting what >> features we do have tested, stabilized, bug fixed, and turning the buildbots >> green across the board. > > Having been caught by the 2.5 beta deadline with the changes that eventually > became PEP 361 (and I think were significantly improved by the additional > attention that was available due to the delay) I understand completely. > > (And to everyone with features that get bumped to 2.7/3.1 because of this... > while a number of you no doubt know this already, it really is astonishing > how soon the next release seems to roll around, even with our fairly > leisurely release schedules!) I'd like to separate the concerns though. I personally don't want to see the feature in its current form added to 2.7/3.1 either. As others pointed out, it's a wart on the bin/oct/hex functions. So as far as the feature design goes, I offer some suggestions: a new module; or a new function in math; or a new method on float. Since Raymond is the champion for the feature let him choose the API from those alternatives. Regarding the addition to 2.6/3.0 post beta 1, I think a new module has the most chance of success, especially if it's written in Python in such a way as to need minimal changes between 2.6 and 3.0. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
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