On 03/08/2016 22:39, Chris Angelico wrote:
On Thu, Aug 4, 2016 at 6:53 AM, BartC <b...@freeuk.com> wrote:
On 03/08/2016 21:12, Chris Angelico wrote:
Fairly common approach - and it means you'll never find those .py
files. So it's no different from looking for sys.py and not finding
it, except that in the case of CPython's sys, it's not even a DLL -
it's part of the interpreter core.
I don't understand. With direct access to msvcrt.dll, the interface to that
will be inside a .py file. Not buried away somewhere else.
Oh. CPython takes a much simpler approach: instead of forcing a Python
module to "think like C", it allows a C module to export functions to
Python. So when you "import math", you actually get something from a
.so/.dll file.
But is this a generic mechanism that works for /any/ .dll file, or does
there have to be dedicated support for each of the 60 built-in modules?
I'm talking about the former.
Then something like a file library can be written in 100% Python, built
around calls to msvcrt.dll for example.
Since such libraries usually come with the OS, anyone investigating how
a library works will see only Python, until it gets to the foreign
functions, which have their own well-documented interface.
You don't just hit a brick wall and be forced to delve into the innards
of CPython, which should be concerning itself with implementing the
language not providing libraries too.
--
Bartc
--
https://mail.python.org/mailman/listinfo/python-list
