Should Python 3 become multi-threaded by design?

[uc1]

Should Python 3 become multi-threaded by design?
To run a program, Python would create a virtual computing pull of all available cores => run every command of the program on a separate core simultaneously => add the result & the index to the mutual memory block => threads would be returning results either as they are completed or the parsed result at the end, depending on whether it's a function or not

For example, let's say we have test.py containing the following code:

my_list = ["apple", "banana", "orange", "potato"]
for i in my_list:
   print(i)

print("this will run & stored in memory before for loop is finished")

We run this file by executing this command:

python -t4 test.py

Python does the following initialization:

- available threads: 4
- assign my_list[0] to thread 0
- assign my_list[1] to thread 1
- assign my_list[2] to thread 2
- assign my_list[3] to thread 3
- [for loop] => create [mutual_memory_block_id1938574896 = {None, return_immediately=True}]
- [print outside the loop] => create [mutual_memory_block_id7788 = {None, return_immediately=True}]

Threads are running randomly & simultaneously:

thread 2:
- mutual_memory_block_id1938574896.update = [ $my_list[2]{"orange"} ]
- thread 2 => status = "Available'
- thread 2 assigned for the next job =>
- thread 2 runs the "next job" - (print outside the loop) immediately since no additional data required => stores the result => returns when ready: mutual_memory_block_id7788.update = [$print("this will run & stored in memory before for loop is finished")]

thread 0:
- mutual_memory_block_id1938574896.update = [ $my_list[0]{"apple"} , $[2]{"orange"} ]
- thread 0 => prints the [0] element on the screen since {return_immediately=True} and mutual_memory_block_id1938574896[0] is available
- thread 0 => status = "Available'

thread 1:
- mutual_memory_block_id1938574896.update = [ $my_list[0]{"apple"}, $my_list[1]{"banana"}, $my_list[2]{"orange"} ]
- thread 1 => prints the [1] element on the screen since {return_immediately=True} and mutual_memory_block_id1938574896[1] is available
- thread 1 => prints the [2] element on the screen since {return_immediately=True} and mutual_memory_block_id1938574896[2] is available
- thread 1 => status = "Available'

thread 3:
- mutual_memory_block_id1938574896.update = [ $my_list[0]{"apple"}, $my_list[1]{"banana"}, $my_list[2]{"orange"}, $my_list[3]{"potato"} ]
- thread 3 => prints the [3] element on the screen since {return_immediately=True} and mutual_memory_block_id1938574896[3] is available
- thread 3 => status = "Available'

####### for loop is done ########

Meanwhile, in the background - thread 1 (is the first available after thread 0)
- are we there yet? {no}, are we there yet? {no}, are we there yet? {no}, are we there yet? {no} ....
- are we there yet? {YES!},
- get from memory mutual_memory_block_id7788
- output it

####### print outside the loop is done ########

P.S.
if the loop would be inside a function, then the loop, during initialization, would get {return_immediately=False}
1. threads wouldn't return their data immediately and would check if the loop is done & function is ready to return the output
2. the first available thread would be gathering the return values and compile it in memory, adding the new bits of data from other cores, and in the end it would get the value from memory and output it at once, like:
- get from memory mutual_memory_block_id1938574896 = [ $my_list[0]{"apple"}, $my_list[1]{"banana"}, $my_list[2]{"orange"}, $my_list[3]{"potato"} ]
- output it


I'm just a beginner in programming and I'm creating this logic as I write this post, if it's flawed, please don't be too angry with my ignorance, give some useful feedback on why it's a flawed idea, instead. I don't have enough knowledge to implement it myself, so just wanted to share this quick idea with the community and discuss if it's even possible.

[Larz60+]

No

If you need it, write it but don't force it.

[ichabod801]

No. This sort of thing is needed in specialized situations. Therefore, it shouldn't be a fundamental part of a general purpose language.

[nilamo]

If the body of a for loop ran in different threads, for each iteration of the loop, then that means there'd have to be a global mutex that locked all variables, because if any of the threads tried accessing a variable while another thread was updating it, you could have unexpected behavior (which nobody wants). And if there's a global mutex, it'd prevent more than one thread from running concurrently anyway, which eliminates any benefit of actually spawning the threads in the first place.

(don't look too closely at what the threading module does, or what the GIL is) :p

It's been baked into python that only one thing happens at a time for so long, that if there was an update that added concurrency as a core component of the language, a lot of python that was already written might just stop working. And since one of the main benefits of python is the massive repository of code available via pip, that'd be a major negative.

[Skaperen]

i wrote a script to list resources, such as instances, in AWS EC2.  it lists everything from all regions (it gets the list of regions when it runs).  it is nice to see what i have running in all regions at once.  if i give one or more region names on the command, it uses just that list.  it accesses every region in parallel using the multiprocessing module.  even in C i prefer processes over threads (that way each task can have its own stack).  i could have done this in multitasking scheme as i have done many times in C but it would be totally unreadable by then (and i don't know if the botocore library i needed to use would even support that).

if you want a copy:  http://linuxhomepage.com/free/list-aws.py