> OTOH, while the current 2/3 split and maintenance of single source libraries may encourage "documented deprecation" as described in the article, that approach -- with no programmatic deprecation warnings and, consequently, never actually pruning the code of deprecated features, can't be a permanent state of affairs, if Python and its standard library are going to be maintainable in practice -- suggesting that it would be is essentially committing to unbounded accumulation of technical debt in the Python code base.
I'm not sure where you are getting that idea from? PEP 387[0] does indeed recommend programmatic warnings through the `warnings` module and eventual removal of deprecated features.
> I'm not sure where you are getting that idea from?
From the article we are discussing (emphasis added):
---quote--
the widespread development of "single source" Python 2/3 libraries and frameworks strongly encourages the use of "documented deprecation" in Python 3, even when features are replaced with newer, preferred, alternatives. In these cases, a deprecation notice is placed in the documentation, suggesting the approach that is preferred for new code, but no programmatic deprecation warning is added. This allows existing code, including code supporting both Python 2 and Python 3, to be left unchanged (at the expense of new users potentially having slightly more to learn when tasked with maintaining existing code bases).
I'm not sure where you are getting that idea from? PEP 387[0] does indeed recommend programmatic warnings through the `warnings` module and eventual removal of deprecated features.
[0]: http://legacy.python.org/dev/peps/pep-0387/#making-incompati...