On 2019-07-17 02:34, Brett Cannon wrote:
I prefer removal for ease of maintenance (people always want to update code
even if it's deprecated), and to help make sure people who don't read the docs
but discover something via the REPL or something and don't run with warnings on
do not
Jeroen Demeyer wrote:
> I have seen multiple discussions where somebody wants to deprecate a
> useless function but somebody else complains that we cannot do that
> because the function in question cannot be removed (because of backwards
> compatibility). See
Raymond Hettinger wrote:
> > On Jul 13, 2019, at 1:56 PM, Serhiy Storchaka storch...@gmail.com... wrote:
> > Could we strictly define what is considered a public module interface in
> > Python?
> > The RealDefinition™ is that whatever we include in the docs is public,
> > otherwise
> not.
>
We've tried this before, but apparently people were cross-compiling. I'd
suggest not removing them any faster than whatever deprecation applies to the
module on all platforms (which should still be as quickly as possible :-) ).
Cheers,
Steve
On Mon, Jul 15, 2019 at 5:26 PM +0200,
On 2019-07-16 15:33, Inada Naoki wrote:
We currently have a deprecation policy saying that functions deprecated
in version N cannot be removed before version N+2. That's a reasonable
policy but some deprecation purists insist that it MUST (instead of MAY)
be removed in version N+2. Following
On Tue, Jul 16, 2019 at 6:46 PM Jeroen Demeyer wrote:
>
> I have seen multiple discussions where somebody wants to deprecate a
> useless function but somebody else complains that we cannot do that
> because the function in question cannot be removed (because of backwards
> compatibility). See
I have seen multiple discussions where somebody wants to deprecate a
useless function but somebody else complains that we cannot do that
because the function in question cannot be removed (because of backwards
compatibility). See https://bugs.python.org/issue29548 for an example.
We currently
