13

In the parlance of posix and general technical software development. Does an import of a purely python ( not cython or c compiled libraries ) module constitute a dynamic linking?

NathanOliver
  • 171,901
  • 28
  • 288
  • 402
Matt Joyce
  • 2,010
  • 2
  • 20
  • 31
  • Also, would it be considered dynamic linking in regards to the [LGPL](https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License)? I believe it would be, but IANAL. – Mark Ransom Nov 08 '16 at 17:04
  • Yes and no depending on the definition of "dynamic linking". In the usual sense **no**, dynamic linking is only about linking of compiled programs (e.g. ELF executables), not scripts. – Bakuriu Nov 08 '16 at 17:06
  • I am less interested in that, as I am sure there is an argument around whether LGPL means c style linking or something entirely different. – Matt Joyce Nov 08 '16 at 17:06
  • 1
    [How does the GPL static vs. dynamic linking rule apply to interpreted languages?](http://softwareengineering.stackexchange.com/questions/167773/how-does-the-gpl-static-vs-dynamic-linking-rule-apply-to-interpreted-languages) – ndpu Nov 08 '16 at 17:08

1 Answers1

14

No, loading a pure-Python module is not considered a form of dynamic linking.

Traditional dynamic linking loads machine code into a new chunk of memory, and multiple executable processes can be given access (the dynamically linked library only needs to be loaded once, virtual memory takes care of the rest). The linker connects the executable and the dynamic library at runtime.

Loading a Python module, on the other hand, loads the bytecode for the modules into the Python process itself (Python will compile the source code if no bytecode cache is available at this time too). The loaded modules are not shared between processes. No translation has to take place, the result of running the bytecode produces new objects in the Python heap that all existing code in the interpreter can interact with.

No linker is involved in this process, no separate memory, to the OS there are no separate sections of memory to be managed as the module is simply part of the Python process memory.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
  • Thanks. by "Loading a Python module, on the other hand" in Python, do you mean import statement or __import__() builtin function, or both, as in https://stackoverflow.com/questions/28231738/import-vs-import-vs-importlib-import-module/28231805#28231805 ? – Tim Jun 10 '18 at 17:41
  • @Tim: both, the `import` statement uses the `__import__()` hook to do its work. – Martijn Pieters Jun 10 '18 at 18:38
  • Thanks. Are both `import` statement and `__import__()` function belonging to https://en.wikipedia.org/wiki/Dynamic_loading or https://en.wikipedia.org/wiki/Dynamic_linking? If neither, what are they belong to, or which one are they more close to? – Tim Jun 10 '18 at 18:41
  • 1
    It is neither. Python is not using OS-level library sharing to load bytecode data. From the OS point of view, Python modules are just data files. – Martijn Pieters Jun 10 '18 at 19:11
  • Thanks. What if we generalize the concepts of dynamic loading and dynamic linking from OS to Python interpreter or virtual machine? Are both import statement and __import__() function belonging to generalized "dynamic loading" or generalized "dynamic linking"? If neither, what are they belong to, or which one are they more close to? – Tim Jun 10 '18 at 19:26
  • @Tim what are you trying to get to here? You can’t compare those very specific techniques, period. – Martijn Pieters Jun 10 '18 at 20:20