(original) (raw)
On Tue, 8 Sep 2015 at 11:36 Terry Reedy <tjreedy@udel.edu> wrote:
On 9/8/2015 12:59 PM, Brett Cannon wrote:
\> There are two discussions going on in the issue tracker about
\> deprecating some modules and it has led to the inevitable discussion of
\> Python 2/3 compatibility (I'm not even going to bother mentioning the
\> issue #s as this thread is not about the modules specifically but module
\> deprecation in general). Because I'm tired of rehashing the same
\> discussion every time a module deprecation comes up I would like to make
\> an official decision that we can follow any time we decide to deprecate
\> a module.
Would you consider the 'official decision' as applying to idlelib
modules? The issue here is not especially related to 2.7\. PEP 434
formalized the idea that idlelib is mostly private, but acknowledged
that there might be unauthorized module uses here and there. The first
example is removing idlelib.idlever, now unused by Idle itself (#21499).
I consider IDLE so far outside the normal process of everything when it comes to stdlib that it is exempt from everything so I don't care if you take a module out completely.
\> The approaches to module deprecation I have seen are:
\> 1\. Nothing changes to the deprecation process; you deprecate a module
\> and remove it in one to two releases
\> 2\. Deprecate the module but with no plans for removal until Python 2.7
\> reaches its EOL (I have been calling this Python 4)
For either 1 or 2, the 2.7 code should get a py3 warning.
I think that's redundant. People who need to run in both Python 2 and 3 will see the warning under Python 3\. I view Py3kWarning for things that would pass silently otherwise or have an odd error message under Python 3\. In this case the message will be clear in Python 3 and thus not a problem.
\> 3\. Document the deprecation but no actual code deprecation
Number 3 creates a discrepancy between code and doc. This is normally
considered a bug, and might be seen as such by someone reading both
unless a comment were inserted into the code.
\> I'm personally in the #2 camp. I want users to be fully aware that the
\> module in question is not being updated and possibly not even getting
\> non-critical bugfixes, but it's still there in Python 3 in order to make
\> sure that you can have code which straddles Python 2 & 3 more easily.
There will be people who convert after 2020, but the final 3.x before
removal will always be available. I also see this as the best of
imperfect choices.
Yep. And people who want to see the modules to continue to exist can take the modules and either vendor them or develop their own group of developers around it and continue their maintenance outside of the stdlib.
-Brett
\> I don't like #1 because when the module exists in python 2.7 as it makes
\> transitioning from Python 2 a bit harder. Leaving code in the stdlib as
\> deprecated isn't going to kill us, especially if we make it clear the
\> code only exists for transitioning purposes and you very well may have
\> to work around any bugs you come across (and yes, this means changing my
\> stance for the formatter module's deprecation).
Idlelib currently has about 6 module-naming conventions, and it was
omitted from the 3.0 renaming. Even without an immediate mass PEP8
rename (#24225), which would help Idle maintenance, new files from
refactoring and ttk conversions will result in a large number of
eventually unused old files. I would prefer to remove them before 2020.
\> I don't like #3 because if you have an API memorized or you copied some
\> code you found online you very well may not realize a module is
\> deprecated. It's not difficult to silence a deprecation warning and you
\> can make it so that even if you use -Werror your deprecated module
\> imports continue to work without throwing an exception while all other
\> deprecations do throw an exception.
\>
\> Whatever decision we come to I will update PEP 4 and then personally go
\> through the various deprecated modules in Python 3.6 and tweak them as
\> necessary to follow whatever policy we come up with.
\--
Terry Jan Reedy
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org