Berker Peksag added the comment:
The docs for old API already say:
Old getter/setter API for name; use it directly as a property instead.
https://docs.python.org/3.5/library/threading.html#threading.Thread.getName
Users don't read the documentation every six or fifteen months so it would be
nice to document old APIs properly as deprecated. And I don't think
documentation-only deprecation would work. See issue 25964 for a real world
example. Users still don't know that optparse is deprecated.
> We don't have to deprecate this for any reason other than to satisfy a
> personal sense of neatness and compactness.
The original request came from a Python user, not from a new generation
perfectionist core developer.
> For the sake of developers who rely on the standard library being "standard"
> and for the mountains of existing code on PyPI, we need to have a strong
> aversion to unnecessary deprecations.
That doesn't mean we shouldn't tell users "Hey, there is a new API which was
added back in 2008. Use it if you want to."
> [...] and they increase the likelihood that package distributors will
> monkey-patch or duplicate the code to restore prior behavior (for example,
> the Hypothesis project will likely have to duplicate the code that was
> recently taken out of the inspect module in favor of signature objects).
I'm not sure we are on the same page here. I already said that I don't want to
remove the old API, but document it properly as deprecated. The inspect case
you've mentioned has already been solved in issue 25486. See issue 26069 (old
trace API) and issue 26041 (platform.dist() and platform.linux_distribution()
deprecation) for my views on deprecation policy.
> We should put more focus on proposed new APIs and making sure that they are
> something we want to live with for a very long time.
Agreed, but we need to advertise new APIs better. Otherwise no one is going to
notice and use them. I think deprecating old APIs (with a clear upgrade path)
would be a good way to promote new ones.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue24203>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
