On Mon, May 05, 2003 at 08:03:58AM -0400, Guido van Rossum wrote:
> > I was wondering if a milder form of deprecation may be appropriate for
> > some features such as the apply builtin:
> >
> > 1. Add a notice in docstring 'not recommended for new code'
> > 2. Move to 'obsolete' or 'backward compatibility' section in manual
> > 3. Do NOT produce a warning (pychecker may still do that)
> > 4. Do NOT plan removal of feature in a specific future release
>
> The form of deprecation used for apply() is already very mild (you
> don't get a warning unless you do -Wall). I don't think Moshe's use
> case is important enough to care; if Moshe cares, he can easily
> construct a command line argument or warnings.filterwarning() call to
> suppress the warnings he doesn't care about.
My comment was not specifically about Moshe's use case - it's about the
meaning of deprecation in Python.
Does it always have to mean "start replacing because it *will* go away"
as seems to be implied by PEP 5 or perhaps in some cases it could just
mean "please don't use this in new code, okay" ?
Oren
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