4 ms·

Slightly off-topic: One of the simplest import systems I've seen were in q/kdb (like with most things in that language, everything is as simple as possible) I

by maest 5y ago

Slightly off-topic: One of the simplest import systems I've seen were in q/kdb (like with most things in that language, everything is as simple as possible) Imports work by simply calling `\l my_script.q` which is similar to simply taking the file `my_script.q` and running it line by line (iirc, it does so eagerly, so it reruns the entire file whenever you do `\l my_script.q`, even if the file has been loaded before, which may affect you state. By contrast, Python `import` statements are no-ops if the module has already been imported). The main disadvantage is that you risk your imported script overwriting your global variables. This is solved by following the strong (unenforced) conversion that scripts should only affect their own namespaces (which works by having the script write declare \d .my_namespace at the top of the script) I never found this system limiting and always appreciated its simplicity - whenever things go wrong debugging is fairly easy. What does Python gain by having a more sophisticated import system?

wizzwizz4 5y ago
Everything is an object, and it “just works” for most purposes. (Not nearly as many as I would like, but still; it has backwards-compatibility to consider, so I'll cut it some slack.) If you need to start installing your own user packages, you need `pip` and then `venv` and then things get ugly, but for the usual case where the sysadmin deals with all that (or you're on Windows), it works quite well.
__float 5y ago
Python imports aren't necessarily always importing Python source code -- they can be pyc (bytecode) files, or C API extensions, etc. These are slightly more complicated than "load the script at this path". There's probably a more detailed answer, in that historically, decisions were made that we're now stuck with. Python packages can and sometimes intentionally have import-time side effects, for example. They must be only run once, without relying on convention, or we break existing code.
btilly 5y ago
Python avoids having to rerun the import over and over again. Suppose that you are importing a larger project. Where your one import (say of your standard database interface) pulls in a group of modules (say one for each table in your database), all of which import a couple of base libraries (to make your database objects provide a common interface) that themselves pull in common Python modules (like psychopg2) which themselves do further imports of standard Python modules. The combinatorial explosion of ways to get to those standard Python modules would make the redundant work of parsing them into a significant time commitment without a caching scheme. From the point of view of a small script, this kind of design may seem like overkill. But in a large project, it is both reasonable and common.
- AlphaSite 5y ago
  Yep. Rerunning things is how you end up with C/C++ style headers and all the (performance and otherwise) problems there in.

by maest 5y ago

wizzwizz4 5y ago

Everything is an object, and it “just works” for most purposes. (Not nearly as many as I would like, but still; it has backwards-compatibility to consider, so I'll cut it some slack.) If you need to start installing your own user packages, you need `pip` and then `venv` and then things get ugly, but for the usual case where the sysadmin deals with all that (or you're on Windows), it works quite well.

__float 5y ago

Python imports aren't necessarily always importing Python source code -- they can be pyc (bytecode) files, or C API extensions, etc. These are slightly more complicated than "load the script at this path". There's probably a more detailed answer, in that historically, decisions were made that we're now stuck with. Python packages can and sometimes intentionally have import-time side effects, for example. They must be only run once, without relying on convention, or we break existing code.

btilly 5y ago

Python avoids having to rerun the import over and over again. Suppose that you are importing a larger project. Where your one import (say of your standard database interface) pulls in a group of modules (say one for each table in your database), all of which import a couple of base libraries (to make your database objects provide a common interface) that themselves pull in common Python modules (like psychopg2) which themselves do further imports of standard Python modules. The combinatorial explosion of ways to get to those standard Python modules would make the redundant work of parsing them into a significant time commitment without a caching scheme. From the point of view of a small script, this kind of design may seem like overkill. But in a large project, it is both reasonable and common.

AlphaSite 5y ago
Yep. Rerunning things is how you end up with C/C++ style headers and all the (performance and otherwise) problems there in.