In module "threading", class "Thread" defines "is_alive" and defines "isAlive = is_alive". The derived class "_DummyThread" redefines "is_alive" but forgets to update the "isAlive" alias. As a consequence, calling "_DummyThread.isAlive" leads to an "AssertionErrror".

The "isAlive" method is mentioned in the docstring of "Thread.join".

Care to open a PR to fix this?

> Care to open a PR to fix this?

I am not familiar with the "github" workflow. The fix is so trivial (add the "isAlive = is_alive" alias to "threading._DummyThread" and replace "isAlive" by "is_alive" in the docstring of "threading.Thread.join" that it does not seem worth to learn the "github" workflow just for this fix.

Hi, Can I work with this issue if no one works on it?

isAlive() is the part of the old API. It is not even documented in Python 3, and can be removed in future. It is better to remove it from docstrings.

And since threads support no longer optional, are there reasons to keep _DummyThread?

If it's not already deprecated, I'd say deprecate it first.

@serhiy.storchaka @pitrou
Then should we add the deprecated message 
for isAlive of class "Thread" first?

The only _DummyThread usage is `threading.current_thread()`:

> If the caller's thread of control was not created through the threading
> module, a dummy thread object with limited functionality is returned.

I guess the question is whether any other Python implementation is threadless? E.g. is MicroPython? If it even has threads then I agree about deprecating the module.

But if MicroPython does support threads we should keep the module. That would mean updating all references of isAlive() to is_alive() and adding the name alias since that name aliasing still exists in 'master' right now (probably for Python 2 porting support): https://github.com/python/cpython/blob/3bb183d7fb83ad6a84ec13dea90f95d67be35c69/Lib/threading.py#L1094

@dmaurer totally understand about time restraints, but do realize even "trivial" fixes like this would still take at least an hour to do a proper job so there's no guarantee someone will get around to fixing this. But if you do change your mind and want to give it a try, then https://devguide.python.org/ is there to help.

> I guess the question is whether any other Python implementation is threadless?

emscripten python ( cpython on asm.js or webassembly ) is threadless

about micropython, only unix port have thread basic implementation and garbage collector messes with EINTR actually so it is not very useable.

unix port is only one on many, and is the less interesting port apart from running quick simulations.

Well, to satisfy everybody we need to:
1. Implement `isAlive` for dummy thread
2. Add a deprecation warning for both Thread.isAlive and _DummyThread.isAlive
3. Remove isAlive in future Python release (3.8 for the deprecation, 3.8+2 for removal).
4. Backporting the property down to 3.7 and 3.6 doesn't hurt, let's do it

Did I miss something?

@asvetlov

I agree with asvetlov :)

I think the only thing missing from your list, Andrew, is updating docstrings and such to mention is_alive() instead of isAlive().

Hi, I am going to solve this issue through below process.

1. Implement `isAlive` for dummy thread
2. Updating docstrings to recommend use is_alive() instead of isAlive().
3. Add a deprecation warning for both Thread.isAlive and _DummyThread.isAlive
4. Remove isAlive in future Python release (3.8 for the deprecation, 3.8+2 for removal).
5. Backporting the property down to 3.7 and 3.6 doesn't hurt, let's do it

Is it okay?

> Hi, I am going to solve this issue through below process.
> ...
> Is it okay?

For me, this would be perfect.

I suggest to start with:

* Updating docstrings to recommend use is_alive() instead of isAlive(), and add a deprecation warning for Thread.isAlive

We may apply such changes to Python 3.7, maybe also emit a PendingDeprecationWarning.

@vstinner
Thanks, I've submitted PR 11459 for 3.7 which emit PendingDeprecationWarning.

New changeset 89669ffe10a9db6343f6ee42239e412c8ad96bde by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-35283: Add deprecation warning for Thread.isAlive (GH-11454)
https://github.com/python/cpython/commit/89669ffe10a9db6343f6ee42239e412c8ad96bde

Ok, master now emits a deprecation warning. Is it worth it to emit a pending deprecation warning in Python 3.7?

I think yes.
People will be notified about depreciation earlier, even after 3.8 release not everybody switches to a new version fast.
For example, I still use 3.6 for my job now (but we are planning to switch to 3.7 in a month or two).
Adding PendingDeprecationWarning to 3.7 is safe, I expect a very few code uses `.isAlive()` on Python 3.

Great!
Should we notify this deprecation also on Doc/whatsnew/3.7.rst?

Not sure. IMHO it is not a *notable* change worth to be mentioned in https://docs.python.org/3/whatsnew/3.7.html#notable-changes-in-python-3-7-2

I've upload PR 11604
Thanks always

New changeset 36d9e9a4d5238d5a2f09679b6c51be66fbfc12c4 by Victor Stinner (Dong-hee Na) in branch 'master':
bpo-35283: Update the docstring of threading.Thread.join method (GH-11596)
https://github.com/python/cpython/commit/36d9e9a4d5238d5a2f09679b6c51be66fbfc12c4

New changeset c2647f2e45d2741fc44fd621966e05d15f2cd26a by Victor Stinner (Dong-hee Na) in branch '3.7':
bpo-35283: Add pending deprecation warning for Thread.isAlive (GH-11604)
https://github.com/python/cpython/commit/c2647f2e45d2741fc44fd621966e05d15f2cd26a