classification
Title: Deprecate threading.Thread.isDaemon etc
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.6
process
Status: closed Resolution: duplicate
Dependencies: Superseder: Deprecate camelCase aliases from threading.py
View: 43723
Assigned To: Nosy List: anon, berker.peksag, r.david.murray, rhettinger
Priority: normal Keywords: patch

Created on 2015-05-15 16:38 by anon, last changed 2021-06-24 13:59 by iritkatriel. This issue is now closed.

Files
File name Uploaded Description Edit
issue24203.diff berker.peksag, 2015-12-13 00:14 review
Messages (6)
msg243277 - (view) Author: anon (anon) Date: 2015-05-15 16:38
In threading.Thread isDaemon, setDaemon, getName, setName are not needed since 2.6 (preferring directly changing daemon or name instead). They should probably be depreciated in 3.5 and removed later. isAlive has already been removed.
msg254345 - (view) Author: anon (anon) Date: 2015-11-08 16:40
Any consensus?
msg256304 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2015-12-13 00:14
+1 for deprecating them. Removing them would make porting code from Python 2 harder so I think it's better to keep them for a while.
msg256310 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2015-12-13 02:02
> Removing them would make porting code from Python 2 harder
> so I think it's better to keep them for a while.

So, no deprecations.  The API is now a bit redundant but it isn't broken or problematic in any way.  We don't have to deprecate this for any reason other than to satisfy a personal sense of neatness and compactness.

This API has long history.  See  https://docs.python.org/release/1.5.2/lib/thread-objects.html.   The older the API, the more likely that there is a lot of existing code that relies on the API (including public and private projects that no longer have an active maintainer or adequate tests).

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.  The deprecations cause headaches for users, they present obstacles to upgrading Python, 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).

Put me down for a -1 on a unnecessary deprecation.  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.  The saying is that the standard library is where code goes to die and it should preferably be dead-on-arrival (one reason that Requests is not be added to the standard library is that the code is still living and evolving).
msg256328 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-12-13 18:46
Well, the idea would be to do a documentation-only deprecation; as in, effectively: this is the older API, you probably really want to use this newer API that is more convenient.  I don't have a strong opinion either way in this case.
msg258170 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2016-01-13 21:18
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.
History
Date User Action Args
2021-06-24 13:59:45iritkatrielsetstatus: open -> closed
superseder: Deprecate camelCase aliases from threading.py
resolution: duplicate
stage: patch review -> resolved
2016-01-13 21:18:27berker.peksagsetmessages: + msg258170
2015-12-13 18:46:39r.david.murraysetnosy: + r.david.murray
messages: + msg256328
2015-12-13 02:02:22rhettingersetnosy: + rhettinger
messages: + msg256310
2015-12-13 00:14:13berker.peksagsetfiles: + issue24203.diff


keywords: + patch
stage: patch review
title: Depreciate threading.Thread.isDaemon etc -> Deprecate threading.Thread.isDaemon etc
nosy: + berker.peksag
versions: + Python 3.6
messages: + msg256304
components: + Library (Lib)
type: enhancement
2015-11-08 16:40:31anonsetmessages: + msg254345
2015-05-15 16:38:54anoncreate