Feature Request:

Where we can use custom Names for separate threads submitted in ThreadPoolExecutor. 

It achieves by sending the name string to _work_queue of ThreadPoolExecutor and then in _worker function modifies the name of the current thread (through name property).

Feature requests are only considered for Python versions that have not yet been released, so only 3.11 should be listed in the "versions" for this ticket.

ThreadPool handles tasks concurrently through Threads so users need not worry about the creation/deletion of Threads, it uses reuses threads whenever possible and it can handle any tasks. 

However, it should be possible for users to at least name/rename according to the tasks that the user submits into the ThreadPool.

Advantages:
* Good for Debugging (so user can know which thread has caused the issue)
* threadName attribute in logging's LogRecord can now use custom Name provided to the Task.

Until now thread_name_prefix parameter allows us to name the threads but those are not particular to the Task.

Price

previously one could write .submit(function_name, *args, **kwargs)
but now one should write 
.submit(function_name, name_of_thread, *args, **kwargs)
name_of_thread can be None

> previously one could write .submit(function_name, *args, **kwargs)
> but now one should write 
> .submit(function_name, name_of_thread, *args, **kwargs)
> name_of_thread can be None

This approach can't work, I'm afraid: it would be a backwards-incompatible change to the `submit` method signature, and would break many existing uses of submit.

There is a new function submit_with_name in _base.Executor that can accept name parameters before args and kwargs, submit can continue to be used as before.

submit internally calls submit_with_name with name as None. Calling submit_with_name in Executor causes a NotImplementedError, it was only implemented in ThreadPoolExecutor, but it could be implemented in any Executor

In summary;
==========

Current Problem:
------------------
 
ThreadPoolExecutor handles all threads-related activities so the user needs to just submit tasks and set max_workers and other Executor settings if necessary. If ThreadPoolExecutor allowed us to name/rename threads, that would be great.

Of Course, there's a workaround that requires the user to change the name of the current Thread inside the Task, but that requires the user to access the current thread which I believe is not the goal of Thread Pool Executor.

Request;
----------

Changes Made:
~~~~~~~~~~~
In this Pull request, _work_queue puts tuple of Future Object and name (name can be None).  i.e, typing.Tuple[_base.Future, typing. Optional[str]] which was just a _base.Future before.

So, inside the _worker function,
When it gets the elements and If its name is None, it will either use the thread_name_prefix or custom Name of task that was used before. else it sets the name of the current Thread with the given name.

Problems it solves
~~~~~~~~~~~~~

Currently, ThreadExecutor uses thread_name_prefix + index number for the Internal Thread which is not enough for debugging when we try to submit different types of Tasks (types here mean general callable). 

So, using this Optional Feature which allows users to submit tasks with names it allows them to easily find issues using the name of Thread either in Logger or in the debugger.

Sorry Rahul: I'm not the right person to help you push this forward.

I'm sympathetic to the problem: I've encountered similar issues in "Real Code", where we needed to associate log outputs generated by worker pool threads with the actual tasks that generated those logs. But I'm not convinced either that setting the thread name is the right mechanism to get that association (it doesn't extend nicely to other executor types, for example), or that the API you propose is the right one (I find the duplication between `submit` and `submit_with_name` to be a bit much).

I'm wondering whether there's some way that executors could use contextvars to provide a per-task context. Then a task "name" could potentially be part of that context, and possibly you could write a custom log handler that read the name from the context when emitting log messages.

If you want to find someone to help push this forward, it may be worth posting on the python-ideas mailing list to get discussion going.

Yes, it's true, it's so naive method, Contextvars! may be inside the Future Object?