You are completely right. Why don't they write their stuff in another language? They've got the resources. Now the rest of the world will suffer the consequences, one of which may be that the devs of native libs will simply abandon the work, or that those libs will become too difficult to use for the casual or starting programmer, completely defeating the purpose.
I'm fine with two builds, but not a single non-GIL build.
> Now the rest of the world will suffer the consequences, one of which may be that the devs of native libs will simply abandon the work, or that those libs will become too difficult to use for the casual or starting programmer, completely defeating the purpose.
Or get the benefits, so casual or starting programmers won't be wondering why their python program refuses to go above 100% CPU, or have to deal with the bullshit of multiprocessing.
> I'm fine with two builds, but not a single non-GIL build.
That might have been the original intention. The latest notice from the SC says:
Our base assumptions are:
* Long-term (probably 5+ years), the no-GIL build should be the only build. We do not want to create a permanent split between with-GIL and no-GIL builds (and extension modules).
They repeat it later. It looks as if they really want to remove it.
> have to deal with the bullshit of multiprocessing
The problems multi-threading introduces outweigh that by far.
I'm fine with two builds, but not a single non-GIL build.