How does/should global data in modules across packages be managed in Python/other languages?

Question

I am trying to design the package and module system for a programming language (Heron) which can be both compiled and interpreted, and from what I have seen I really like the Python approach. Python has a rich choice of modules, which seems to contribute largely to its success.

What I don`t know is what happens in Python if a module is included in two different compiled packages: are there separate copies made of the data or is it shared?

Related to this are a bunch of side-questions:

1. Am I right in assuming that packages can be compiled in Python?
2. What are there pros and cons to the two approaches (copying or sharing of module data)?
3. Are there widely known problems with the Python module system, from the point of view of the Python community? For example is there a PEP under consideration for enhancing modules/packages?
4. Are there certain aspects of the Python module/package system which wouldn`t work well for a compiled language?

Answer 1

Global data is scoped at the interpreter level.

1. "packages" can be compiled as a package is just a collection of modules which themselves can be compiled.
2. I am not sure I understand given the established scoping of data.

Answer 2

Well, you asked a lot of questions. Here are some hints to get a bit further:

1. a. Python code is lexed and compiled into Python specific instructions, but not compiled to machine executable code. The ".pyc" file is automatically created whenever you run python code that does not match the existing .pyc timestamp. This feature can be turned off. You might play with the dis module to see these instructions. b. When a module is imported, it is executed (top to bottom) in its own namespace and that namespace cached globally. When you import from another module, the module is not executed again. Remember that def is just a statement. You may want to put a print('compiling this module') statement in your code to trace it.

2. It depends.

3. There were recent enhancements, mostly around specifying which module needed to be loaded. Modules can have relative paths so that a huge project might have multiple modules with the a same name.

4. Python itself won't work for a compiled language. Google for "unladen swallow blog" to see the tribulations of trying to speed up a language where "a = sum(b)" can change meanings between executions. Outside of corner cases, the module system forms a nice bridge between source code and a compiled library system. The approach works well, and Python's easy wrapping of C code (swig, etc.) helps.