Choosing an official stance towards module deprecation in Python 3
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. 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) 3. Document the deprecation but no actual code deprecation 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. 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). 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.
#2 sounds fine to me. On Tue, Sep 8, 2015 at 9:59 AM, Brett Cannon <bcannon@gmail.com> 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.
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) 3. Document the deprecation but no actual code deprecation
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.
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).
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.
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On September 8, 2015 at 1:01:14 PM, Brett Cannon (bcannon@gmail.com) wrote:
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) 3. Document the deprecation but no actual code deprecation
A riff on #1, is that it gets packaged up separately and released on PyPI, this is basically what Django did when it removed django.contrib.comments from Django. This kind of walks a line between 1 and 2 where the module is no longer in the standard library, but if people are actually using those things, then they are a fairly easy ``pip install`` away. This obviously only works for "leaf" modules that don't have other parts of the standard library depending on them, but #1 wouldn't work fo those anyways. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Tue, 8 Sep 2015 at 10:08 Donald Stufft <donald@stufft.io> wrote:
On September 8, 2015 at 1:01:14 PM, Brett Cannon (bcannon@gmail.com) wrote:
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) 3. Document the deprecation but no actual code deprecation
A riff on #1, is that it gets packaged up separately and released on PyPI, this is basically what Django did when it removed django.contrib.comments from Django. This kind of walks a line between 1 and 2 where the module is no longer in the standard library, but if people are actually using those things, then they are a fairly easy ``pip install`` away. This obviously only works for "leaf" modules that don't have other parts of the standard library depending on them, but #1 wouldn't work fo those anyways.
That is one possibility, but I notice that django.contrib.comments is still getting updated. For deprecated modules they probably won't even get bugfixes anymore so I wouldn't want to give the wrong impression the modules are still being maintained. Plus we would have to figure out who is in charge of the actual project on PyPI since there isn't a concept of group ownership.
On September 8, 2015 at 1:29:58 PM, Brett Cannon (bcannon@gmail.com) wrote:
That is one possibility, but I notice that django.contrib.comments is still getting updated. For deprecated modules they probably won't even get bugfixes anymore so I wouldn't want to give the wrong impression the modules are still being maintained. Plus we would have to figure out who is in charge of the actual project on PyPI since there isn't a concept of group ownership.
I don't really much care which way it is done, I was just throwing it out there as a possibility. Though I think the first problem is solvable by clear documentation. Actually in Django's case I think it was "Ok we've removed it, if somebody wants to step up and maintain it they can, otherwise it's going to wither and die on it's own", but my memory might be faulty. The second problem is easier, you can add multiple people to a project, and "Organization/Group" accounts will be something that gets implemented in Warehouse. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
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).
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.
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.
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
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
On 9 September 2015 at 04:56, Brett Cannon <brett@python.org> wrote:
On Tue, 8 Sep 2015 at 11:36 Terry Reedy <tjreedy@udel.edu> wrote:
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.
I was going to make the same suggestion as Terry, but you're right, seeing the warning under 3.x will suffice in these cases. So +1 for simple deprecation without removal until after 2.7 enters security fix only mode. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Tue, Sep 8, 2015 at 7:59 PM, Brett Cannon <bcannon@gmail.com> 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.
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) 3. Document the deprecation but no actual code deprecation
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.
+1 --Berker
Since everyone seems happy with the proposal to keep deprecated modules in Python 3 until Python 2.7 reaches EOL, here are my proposed changes to PEP 4. If no one objects I will commit the change and then update formatter and imp to say they will be removed once Python 2.7 is no longer supported. --- a/pep-0004.txt Fri Sep 11 10:39:21 2015 -0700 +++ b/pep-0004.txt Fri Sep 11 10:39:24 2015 -0700 @@ -2,7 +2,7 @@ Title: Deprecation of Standard Modules Version: $Revision$ Last-Modified: $Date$ -Author: Martin von Löwis <martin@v.loewis.de> +Author: Brett Cannon <brett@python.org>, Martin von Löwis < martin@v.loewis.de> Status: Active Type: Process Content-Type: text/x-rst @@ -50,6 +50,15 @@ releases that immediately follows the deprecation; later releases may ship without the deprecated modules. +For modules existing in both Python 2.7 and Python 3.5 +------------------------------------------------------ +In order to facilitate writing code that works in both Python 2 & 3 +simultaneously, any module deprecated from Python 3.5 onwards that +also exists in Python 2.7 will not be removed from the standard +library until Python 2.7 is no longer supported. Exempted from this +is any module in the idlelib package as well as any exceptions +granted by the Python development team. + Procedure for declaring a module undeprecated ============================================= @@ -258,12 +267,16 @@ Remove from 2.7 Documentation: None + Module name: imp + Rationale: Replaced by the importlib module. + Date: 2013-02-10 + Documentation: Deprecated as of Python 3.4. + Module name: formatter Rationale: Lack of use in the community, no tests to keep code working. - Documentation: Deprecated as of Python 3.4 by raising - PendingDeprecationWarning. Slated for removal in - Python 3.6. + Date: 2013-08-12 + Documentation: Deprecated as of Python 3.4. Deprecation of modules removed in Python 3.0 On Tue, 8 Sep 2015 at 09:59 Brett Cannon <bcannon@gmail.com> 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.
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) 3. Document the deprecation but no actual code deprecation
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.
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).
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.
+1. The language seems a bit ambiguous: "deprecated from 3.5 onward" -- what if a module was deprecated in 3.3 or 3.4 but still present in 3.5? I assume those are also included, but the language makes it possible to interpret this as applying only to modules that were first marked as deprecated in 3.5... On Fri, Sep 11, 2015 at 10:42 AM, Brett Cannon <bcannon@gmail.com> wrote:
Since everyone seems happy with the proposal to keep deprecated modules in Python 3 until Python 2.7 reaches EOL, here are my proposed changes to PEP 4. If no one objects I will commit the change and then update formatter and imp to say they will be removed once Python 2.7 is no longer supported.
--- a/pep-0004.txt Fri Sep 11 10:39:21 2015 -0700 +++ b/pep-0004.txt Fri Sep 11 10:39:24 2015 -0700 @@ -2,7 +2,7 @@ Title: Deprecation of Standard Modules Version: $Revision$ Last-Modified: $Date$ -Author: Martin von Löwis <martin@v.loewis.de> +Author: Brett Cannon <brett@python.org>, Martin von Löwis < martin@v.loewis.de> Status: Active Type: Process Content-Type: text/x-rst @@ -50,6 +50,15 @@ releases that immediately follows the deprecation; later releases may ship without the deprecated modules.
+For modules existing in both Python 2.7 and Python 3.5 +------------------------------------------------------ +In order to facilitate writing code that works in both Python 2 & 3 +simultaneously, any module deprecated from Python 3.5 onwards that +also exists in Python 2.7 will not be removed from the standard +library until Python 2.7 is no longer supported. Exempted from this +is any module in the idlelib package as well as any exceptions +granted by the Python development team. +
Procedure for declaring a module undeprecated ============================================= @@ -258,12 +267,16 @@ Remove from 2.7 Documentation: None
+ Module name: imp + Rationale: Replaced by the importlib module. + Date: 2013-02-10 + Documentation: Deprecated as of Python 3.4. + Module name: formatter Rationale: Lack of use in the community, no tests to keep code working. - Documentation: Deprecated as of Python 3.4 by raising - PendingDeprecationWarning. Slated for removal in - Python 3.6. + Date: 2013-08-12 + Documentation: Deprecated as of Python 3.4.
Deprecation of modules removed in Python 3.0
On Tue, 8 Sep 2015 at 09:59 Brett Cannon <bcannon@gmail.com> 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.
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) 3. Document the deprecation but no actual code deprecation
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.
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).
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.
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
Tweaked wording that clearly state the mere existence in both Python 2.7 and 3.5 means the module won't be removed until Python 2.7 is EOL'ed: In order to facilitate writing code that works in both Python 2 & 3 simultaneously, any module that exists in both Python 3.5 and Python 2.7 will not be removed from the standard library until Python 2.7 is no longer supported as specified by PEP 373. Exempted from this rule is any module in the idlelib package as well as any exceptions granted by the Python development team. On Fri, 11 Sep 2015 at 10:47 Guido van Rossum <guido@python.org> wrote:
+1.
The language seems a bit ambiguous: "deprecated from 3.5 onward" -- what if a module was deprecated in 3.3 or 3.4 but still present in 3.5? I assume those are also included, but the language makes it possible to interpret this as applying only to modules that were first marked as deprecated in 3.5...
On Fri, Sep 11, 2015 at 10:42 AM, Brett Cannon <bcannon@gmail.com> wrote:
Since everyone seems happy with the proposal to keep deprecated modules in Python 3 until Python 2.7 reaches EOL, here are my proposed changes to PEP 4. If no one objects I will commit the change and then update formatter and imp to say they will be removed once Python 2.7 is no longer supported.
--- a/pep-0004.txt Fri Sep 11 10:39:21 2015 -0700 +++ b/pep-0004.txt Fri Sep 11 10:39:24 2015 -0700 @@ -2,7 +2,7 @@ Title: Deprecation of Standard Modules Version: $Revision$ Last-Modified: $Date$ -Author: Martin von Löwis <martin@v.loewis.de> +Author: Brett Cannon <brett@python.org>, Martin von Löwis < martin@v.loewis.de> Status: Active Type: Process Content-Type: text/x-rst @@ -50,6 +50,15 @@ releases that immediately follows the deprecation; later releases may ship without the deprecated modules.
+For modules existing in both Python 2.7 and Python 3.5 +------------------------------------------------------ +In order to facilitate writing code that works in both Python 2 & 3 +simultaneously, any module deprecated from Python 3.5 onwards that +also exists in Python 2.7 will not be removed from the standard +library until Python 2.7 is no longer supported. Exempted from this +is any module in the idlelib package as well as any exceptions +granted by the Python development team. +
Procedure for declaring a module undeprecated ============================================= @@ -258,12 +267,16 @@ Remove from 2.7 Documentation: None
+ Module name: imp + Rationale: Replaced by the importlib module. + Date: 2013-02-10 + Documentation: Deprecated as of Python 3.4. + Module name: formatter Rationale: Lack of use in the community, no tests to keep code working. - Documentation: Deprecated as of Python 3.4 by raising - PendingDeprecationWarning. Slated for removal in - Python 3.6. + Date: 2013-08-12 + Documentation: Deprecated as of Python 3.4.
Deprecation of modules removed in Python 3.0
On Tue, 8 Sep 2015 at 09:59 Brett Cannon <bcannon@gmail.com> 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.
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) 3. Document the deprecation but no actual code deprecation
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.
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).
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.
_______________________________________________ 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/guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On Sep 11, 2015, at 1:57 PM, Brett Cannon <bcannon@gmail.com> wrote:
In order to facilitate writing code that works in both Python 2 & 3 simultaneously, any module that exists in both Python 3.5 and Python 2.7 will not be removed from the standard library until Python 2.7 is no longer supported as specified by PEP 373. Exempted from this rule is any module in the idlelib package as well as any exceptions granted by the Python development team.
I think that reads nicely. It makes a clear contract with developers letting them know that we will avoid making their life unnecessarily difficult. Raymond
On 08.09.15 19:59, Brett Cannon wrote:
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) 3. Document the deprecation but no actual code deprecation
Of course #2 LGTM. What if at the same time add Py3k warning in next 2.7 bugfix release?
Someone else brought up warnings in Python 2.7 and my response was that you already get the warning in Python 3 so why get it twice across different versions? On Fri, Sep 11, 2015, 22:48 Serhiy Storchaka <storchaka@gmail.com> wrote:
On 08.09.15 19:59, Brett Cannon wrote:
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) 3. Document the deprecation but no actual code deprecation
Of course #2 LGTM. What if at the same time add Py3k warning in next 2.7 bugfix release?
_______________________________________________ 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
participants (10)
-
Barry Warsaw -
Berker Peksağ -
Brett Cannon -
Brett Cannon -
Donald Stufft -
Guido van Rossum -
Nick Coghlan -
Raymond Hettinger -
Serhiy Storchaka -
Terry Reedy