> Raymond> Yes, I've been keeping it Py2.3 compatible and periodically > Raymond> test it on 2.3 just to make sure. > > Raymond> Am hesitant to introduce this as a specific, on-going > Raymond> restriction to the code, but I don't want to throw-away 2.3 > Raymond> compatibility unless there is a darned good offsetting gain. > > Raymond, > > Given that you've expended effort to keep decimal 2.3-compatible I sort of > doubt at this point that something will be done to make it incompatible > with > 2.3 before 2.4 is released. > > Might I suggest an addition to PEP 291 like this: > > Package/Module Maintainer(s) Python Version Notes > -------------- ------------- -------------- ----- > ... > decimal Raymond, et al 2.3 [2] > ... > > with note 2 being something like: > > Compatibility with 2.3 maintained until at least 2.5 is released. > > The thought there is that after 2.4 is released no new language features > or > modules should be added to 2.4.n (n > 0) which you would want to use in > the > decimal module. If 2.4 is released with a decimal module that is > 2.3-compatible, maintaining that compatibility until 2.5 is released > shouldn't be too difficult. > > The above would satisfy me. Done. Raymond
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