Sophist added the comment:
> https://docs.google.com/document/d/18CXhDb1ygxg-YXNBJNzfzZsDFosB5e6BfnXLlejd9l0/edit
1. The steering committee hasn't given the go ahead for this yet, and we have
no idea when such a decision will be made nor whether the decision with be yes
or no.
2. E
Sophist added the comment:
> I think that we should focus our efforts on removing the GIL, now that we
> have a feasible solution for doing so without breaking anything
Is this really a thing? Something that is definitely happening in a reasonable
timescale?
Or are there so
Sophist added the comment:
Please see also https://github.com/faster-cpython/ideas/discussions/328 for a
proposal for a simple (much simpler than BFS) GIL scheduler only allocating the
GIL between runable O/S threads waiting to have ownership of the GIL, and using
the O/S scheduler
Sophist added the comment:
http://stackoverflow.com/questions/23125857/python-os-path-exists-cant-locate-the-file-however-the-file-indeed-exsits
gave me an explanation:
That when running 32-bit apps on Win 64 C:\Windows\SysWOW64 is mapped to
C:\Windows\system32.
Copying the missing DLL
Changes by Sophist <pyt...@sodalis.co.uk>:
--
versions: -Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue16283>
___
_
Changes by Sophist <pyt...@sodalis.co.uk>:
--
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Sophist added the comment:
Finding it impossible for PIP to install discid.
Tracked it down to this issue i.e.
os.path.isfile('C:\Windows\system32\discid.dll') == False when the dll exists.
Some other dlls in that directory result in True and some in False. I cannot
see any significant
