[Python-Dev] Long-term deprecation policy
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 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 this reasoning, we cannot deprecate something that we cannot remove. Personally, I think that this reasoning is flawed: even if we cannot *remove* a function, we can still *deprecate* it. That way, we send a message that the function shouldn't be used anymore. And it makes it easier to remove it in the (far) future: if the function was deprecated for a while, we have a valid reason to remove it. The longer it was deprecated, the less likely it is to be still used, which makes it easier to remove eventually. So I suggest to embrace such long-term deprecations, where we deprecate something without planning in advance when it will be removed. This is actually how most other open source projects that I know handle deprecations. I'd like to know the opinion of the Python core devs here. Cheers, Jeroen. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/IRUNBGU3GN4XGTXWKFFZZJR7XDOWZWWF/
[Python-Dev] Re: Long-term deprecation policy
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 https://bugs.python.org/issue29548 for an example. > FWIW, we didn't have deprecated macro in 2017. Now we have it and I'm +1 to deprecate it. Especially, I want to force Py_SSIZE_T_CLEAN support (remove int support for #) in early 2020s (3.10, or 3.11). But PyEval_CallFunction and PyEval_CallMethod doesn't respect Py_SSIZE_T_CLEAN. We need breaking behavior change for them. And we raise runtime deprecation warning already. I think we should add compile time warning too, regardless # is used or not. > 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 this reasoning, we cannot deprecate > something that we cannot remove. Really? Any example? > > Personally, I think that this reasoning is flawed: even if we cannot > *remove* a function, we can still *deprecate* it. I totally agree with you. Nothing wrong about long deprecation period. > That way, we send a > message that the function shouldn't be used anymore. And it makes it > easier to remove it in the (far) future: if the function was deprecated > for a while, we have a valid reason to remove it. The longer it was > deprecated, the less likely it is to be still used, which makes it > easier to remove eventually. > > So I suggest to embrace such long-term deprecations, where we deprecate > something without planning in advance when it will be removed. This is > actually how most other open source projects that I know handle > deprecations. > > I'd like to know the opinion of the Python core devs here. > FWIW, there is PendingDeprecationWarning for something discouraged but not deprecated, and will be deprecated in the future. But I prefer simple deprecation. Regards, -- Inada Naoki ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/4KDQ3QNO4YL6FWX6Q6YQVKPINJ7QK2DG/
[Python-Dev] Re: Long-term deprecation policy
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 this reasoning, we cannot deprecate something that we cannot remove. Really? Any example? * https://bugs.python.org/issue29548#msg287775 * https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038/10 and following ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/QUPCYUHYAY5UX7NIBGJ5FVY5EHHIK442/
[Python-Dev] Re: bpo-37468: make install no longer install wininst-*.exe files
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, "Victor Stinner" wrote: Hi, I modified Makefile.pre.in to avoid installing wininst-*.exe files, since these files are only useful on Windows: the distutils bdist_wininst command only works on Windows. https://bugs.python.org/issue37468 I made the assumption that "make install" is only used on Unix, not on Windows. I never tried to build Python in Cygwin or MinGW on Windows. If someone knows these platforms, and consider that wininst-*.exe should still be installed on these platforms, please propose a pull request for bpo-37468. By the way, bdist_wininst is now deprecated in Python 3.8: wheel packages are now preferred. https://bugs.python.org/issue37481 Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/53T647PT4F5QZ5NOX2GDLMMPC5EPJY4Y/ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/NNDDZ5WFKDFU2TCPM6TTKFPFJBNIE5HY/
[Python-Dev] Re: What is a public API?
Raymond Hettinger wrote: > > On Jul 13, 2019, at 1:56 PM, Serhiy Storchaka [email protected]... 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. > Beyond that, there is a question of how users can deduce what is public when > they run > "import somemodule; print(dir(some module))". > In some modules, we've been careful to use both all and to use an > underscore prefix to indicate private variables and helper functions > (collections and > random for example). IMO, when a module has shown that care, future > maintainers should > stick with that practice. > The calendar module is an example of where that care was taken for many years > and then > a recent patch went against that practice. I agree with Raymond that if the calendar module was following the leading underscore practice (which we should probably encourage all new modules to follow for consistency going forward) then I think the module should be updated to keep the practice going. -Brett ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/WRREKS5LYMB5VYFON7RWGDKZW4KTYMIE/
[Python-Dev] Re: Long-term deprecation policy
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 https://bugs.python.org/issue29548... for an > example. > We currently have a deprecation policy saying that functions deprecated > in version N cannot be removed before version N+2. Do we have that officially written down anywhere? The closest I know is https://www.python.org/dev/peps/pep-0387/ but that PEP is still a draft. And for me the "official" policy is if you deprecate in N you can remove in N+1, not N+2. (But all of this is a bit wonky with Python 2.7 still being alive and not being able to remove anything from the stdlib unless it's severely broken until 2.7 hits EOL). > That's a reasonable > policy but some deprecation purists insist that it MUST (instead of MAY) > be removed in version N+2. Following this reasoning, we cannot deprecate > something that we cannot remove. > Personally, I think that this reasoning is flawed: even if we cannot > remove a function, we can still deprecate it. That way, we send a > message that the function shouldn't be used anymore. And it makes it > easier to remove it in the (far) future: if the function was deprecated > for a while, we have a valid reason to remove it. The longer it was > deprecated, the less likely it is to be still used, which makes it > easier to remove eventually. > So I suggest to embrace such long-term deprecations, where we deprecate > something without planning in advance when it will be removed. This is > actually how most other open source projects that I know handle > deprecations. > I'd like to know the opinion of the Python core devs here. 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 accidentally come to rely on something that's deprecated. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/PRI2O6G6O6HUVGXD3W2MSCEF4JTW36IB/
[Python-Dev] Re: Long-term deprecation policy
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 accidentally come to rely on something that's deprecated. I see what you mean but it doesn't really answer my question. I was asking about a scenario where you plan on purpose a long deprecation period because you know in advance that you cannot remove the functionality soon (because of PEP 384 or because it's used a lot, for example collections ABCs). ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/GLFWX7QJ7WKNHHWXJEXMJI5JDCTIGODF/
