On Tuesday 07 December 2004 11:43, Raymond Hettinger wrote:
> > Modules that have currently deprecation messages in them often
> > fail to identify the Python version in which removal will occur.
> > For modules that have been deprecated since 2.1, I would suggest
> > to remove them for 2.5, with the option of bringing them back
> > in 2.5.1 if people complain.
>
> [...]
>
> Also, we need to shy away from the idea of having 2.5.1 with different
> capabilities than 2.5. This sort of thing is a portability disaster.
> Anthony, please speak up.
Sorry - been a bit busy the last few days. Raymond is right here - there's
no way we can or should do this. A bugfix release contains _bugfixes_.
Making new modules available in a bugfix is a sucky sucky approach.
Worse - once we remove a module, it should _stay_ removed. Otherwise,
we're going to end up with crap like:
if sys.version < (2,5) or sys.version >= (2,6):
import froggie
else:
# froggie was removed in 2.5 and reinstated in 2.6
from compat import froggie
and people will be shipping their own versions of the code to get around
our misfeature.
--
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