5 ms·

Python's imports are the worst I've seen in any mainstream programming language by far. Relative path imports are unnecessarily difficult, especially if you wa

by matsz 2y ago

Python's imports are the worst I've seen in any mainstream programming language by far. Relative path imports are unnecessarily difficult, especially if you want to import something from a parent directory. There's no explicit way to define what you'd like to export either. The syntax is inconsistent, too: from X import Y import Z vs. (modern JS) import { Y } from 'X'; import * as Z from 'Z'; Even C/C++ make more sense here.

simonw 2y ago
It took me far longer than I'd like to admit for "import *" in modern JavaScript to make sense to me. Python imports made sense straight away - but then I've been a Python programmer for a long time so I'm far removed from a beginner's perspective.
- jnpnj 2y ago
  Relative imports are fuzzy if you don't dig deep, that said with a project scaffolded for you, it's rarely a headache (like testing in the old days), you can rapidly try various amount of dots.
  - klyrs 2y ago
    I still haven't bothered to learn why relative imports require you to be in a package. It's a major headache if, like me, you do a lot of one-off work that doesn't warrant that project scaffolding. Well, not a major headache. I can always revert to the py2 way: symlinks.
    - Doxin 2y ago
      > It's a major headache if, like me, you do a lot of one-off work that doesn't warrant that project scaffolding. Instead of creating "myproject.py", create a myproject folder with a __main__.py file. Run it as "python -m myproject". Hardly any scaffolding and your code is in a package. It's one of the things I like about python, it's quite easy to move "up the ladder" scaffolding-wise if you need to.
- kragen 2y ago
  also when you were a beginner python imports were much simpler than they are now
- augusto-moura 2y ago
  You have to name a wildcard import: import * as bindingName from 'module-url' All exports are also named, so you get an object with all exports as properties. console.log(bindingName.exportedName) What is so confusing about it? The docs are also pretty clear to me: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#namespace_import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Maybe you meant bare imports? import 'module-url' In that case it only means: execute the code from that module, I don't care about importing stuff. If they set a global variable or interact with other modules I might use it.
  - nick238 2y ago
    As a Python dev, reading the "import * as bindingName from 'module-url'" seems confusing as it sounds like it'd try to assign multiple things to one name. In Python, the following line pairs are roughly equivalent: import X X = __import__("X") or import X as Y Y = __import__("X") I understand and kinda appreciate the nice (apparent) simplicity of a dedicated "import", especially as you will use it a ton, but I also like the bluntness of Zig where it's not special (well, it has a macro), and you're explicitly doing the assignment: const std = @import("std"); const parseInt = std.fmt.parseInt; Really not a fan of languages that allow importing (using, including...) things where magic happens and a bunch of names are just available without any clear idea where from. Yeah, an IDE will help you find the source of a C function from an #include, but if you're trying to debug some 3rd party library and don't want to download the whole thing, the ability to hand-trace it a bit is just gone. Why mix a bunch of names into the local namespace? If you want short names, just assign it to a single letter variable. Circling back to Python, the only practical place I see 'import * from ...` being used is in libraries where they are bundling up names from a bunch of submodules to be accessible at a top-level. Though, I was searching for an example of this as I know NumPy did it until they undid it: https://github.com/numpy/numpy/pull/24357 https://github.com/numpy/numpy/pull/24357
    - augusto-moura 2y ago
      > I understand and kinda appreciate the nice (apparent) simplicity of a dedicated "import", especially as you will use it a ton, but I also like the bluntness of Zig where it's not special (well, it has a macro), and you're explicitly doing the assignment: That is exactly how CommonJS worked for the longest time: const module = require('url') The short end of the stick was the export syntax for CJS, which is basically just assigning a property to an object: module.exports.value = 'foo' The problem solve with the import syntax is that is statically parseable, you just need to parse the top-level of a package to find its dependencies. The explicit export is also a god-send for tooling, which can have a lot of introspection from it, without executing any code.
drhagen 2y ago
I always thought Scala had nice imports [1]: import users.* import users.User import users.{User, UserPreferences} import users.UserPreferences as UPrefs [1] https://docs.scala-lang.org/tour/packages-and-imports.html#imports https://docs.scala-lang.org/tour/packages-and-imports.html#i...
Spivak 2y ago
> Relative path imports are unnecessarily difficult, especially if you want to import something from a parent directory. This is never explained well to beginners but this is because Python imports deal with modules and packages, any relationship with directories is accidental. With namespace packages foo.bar and foo.baz might live on totally separate parts of the filesystem. They might not live on the filesystem at all and instead be in a zip file. somedir/ otherdir/ __init__.py foo.py scripts/ __init__.py myscript.py # in myscript.py from .. import otherdir.foo If you `python scripts/myscript.py` then it won't work because myscript.py is run with a __name__ of __main__ which doesn't have any parent module. When you run python -m scripts.myscript it sets __package__ to scripts.myscript so now it does have a parent module and somedir and otherdir are importable under the root module because '.' is added to the search path by default.
BurningFrog 2y ago
The worst thing is that it can't handle circular imports, unlike every other language, AFAIK. I've been told it's because of some deep part of Python interpretation that just can't be changed. The mutable default argument madness is also caused by that. Anyone know more?
- aeturnum 2y ago
  My guess is that imports in python are just executing python. When you import a module you are (optionally) running code in that module. So a circular import generates infinite recursion. Python does a lot when it evaluates an import statement. That is where a lot of the python magic happens. As soon as you try to limit the import statement somehow, a lot of python code needs to be re-written (and maybe doesn't work at all anymore). That's arguably a bad decision but it's one at the center of the language and it's unlikely to change.
  - augusto-moura 2y ago
    Exactly, importing (like everything else in Python) is just a "syntax sugar" around loading the code on a file and running it instantly. If you do a circular reference it can pop the stack
    - dmurray 2y ago
      > importing (like everything else in Python) is just a "syntax sugar" around loading the code on a file and running it instantly. Not quite - it also checks whether the file has already been imported, and does nothing if so. And it also checks if the file has been "partially imported" which is what causes it to fail during circular imports. You could imagine a small change to Python which made the second case a no-op as well. This would allow you to use circular imports. You'd need to restrict yourself to imports like "import mymodule; mymodule.myfunction()" rather than "from mymodule import myfunction; myfunction()" but that's encouraged in popular style guides [0] anyway. By the time you run the function, mymodule.myfunction will be bound correctly and everything will work. This would create hard-to-debug situations for people who rely on executing lots of side-effect code to set up state at import time, but 1) that would only happen in code that currently can't run at all, and 2) those people deserve it. I think it would even be reasonable to make the "from mymodule" version work by binding those names later, but it wouldn't be a one-line change to the interpreter and it might break some legitimate use cases where a name got redefined. [0] https://google.github.io/styleguide/pyguide.html https://google.github.io/styleguide/pyguide.html

by matsz 2y ago

simonw 2y ago

It took me far longer than I'd like to admit for "import *" in modern JavaScript to make sense to me. Python imports made sense straight away - but then I've been a Python programmer for a long time so I'm far removed from a beginner's perspective.

jnpnj 2y ago
Relative imports are fuzzy if you don't dig deep, that said with a project scaffolded for you, it's rarely a headache (like testing in the old days), you can rapidly try various amount of dots.
- klyrs 2y ago
  I still haven't bothered to learn why relative imports require you to be in a package. It's a major headache if, like me, you do a lot of one-off work that doesn't warrant that project scaffolding. Well, not a major headache. I can always revert to the py2 way: symlinks.
  - Doxin 2y ago
    > It's a major headache if, like me, you do a lot of one-off work that doesn't warrant that project scaffolding. Instead of creating "myproject.py", create a myproject folder with a __main__.py file. Run it as "python -m myproject". Hardly any scaffolding and your code is in a package. It's one of the things I like about python, it's quite easy to move "up the ladder" scaffolding-wise if you need to.
kragen 2y ago
also when you were a beginner python imports were much simpler than they are now
augusto-moura 2y ago
You have to name a wildcard import: import * as bindingName from 'module-url' All exports are also named, so you get an object with all exports as properties. console.log(bindingName.exportedName) What is so confusing about it? The docs are also pretty clear to me: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#namespace_import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Maybe you meant bare imports? import 'module-url' In that case it only means: execute the code from that module, I don't care about importing stuff. If they set a global variable or interact with other modules I might use it.
- nick238 2y ago
  As a Python dev, reading the "import * as bindingName from 'module-url'" seems confusing as it sounds like it'd try to assign multiple things to one name. In Python, the following line pairs are roughly equivalent: import X X = __import__("X") or import X as Y Y = __import__("X") I understand and kinda appreciate the nice (apparent) simplicity of a dedicated "import", especially as you will use it a ton, but I also like the bluntness of Zig where it's not special (well, it has a macro), and you're explicitly doing the assignment: const std = @import("std"); const parseInt = std.fmt.parseInt; Really not a fan of languages that allow importing (using, including...) things where magic happens and a bunch of names are just available without any clear idea where from. Yeah, an IDE will help you find the source of a C function from an #include, but if you're trying to debug some 3rd party library and don't want to download the whole thing, the ability to hand-trace it a bit is just gone. Why mix a bunch of names into the local namespace? If you want short names, just assign it to a single letter variable. Circling back to Python, the only practical place I see 'import * from ...` being used is in libraries where they are bundling up names from a bunch of submodules to be accessible at a top-level. Though, I was searching for an example of this as I know NumPy did it until they undid it: https://github.com/numpy/numpy/pull/24357 https://github.com/numpy/numpy/pull/24357
  - augusto-moura 2y ago
    > I understand and kinda appreciate the nice (apparent) simplicity of a dedicated "import", especially as you will use it a ton, but I also like the bluntness of Zig where it's not special (well, it has a macro), and you're explicitly doing the assignment: That is exactly how CommonJS worked for the longest time: const module = require('url') The short end of the stick was the export syntax for CJS, which is basically just assigning a property to an object: module.exports.value = 'foo' The problem solve with the import syntax is that is statically parseable, you just need to parse the top-level of a package to find its dependencies. The explicit export is also a god-send for tooling, which can have a lot of introspection from it, without executing any code.

drhagen 2y ago

I always thought Scala had nice imports [1]: import users.* import users.User import users.{User, UserPreferences} import users.UserPreferences as UPrefs [1] https://docs.scala-lang.org/tour/packages-and-imports.html#imports https://docs.scala-lang.org/tour/packages-and-imports.html#i...

Spivak 2y ago

> Relative path imports are unnecessarily difficult, especially if you want to import something from a parent directory. This is never explained well to beginners but this is because Python imports deal with modules and packages, any relationship with directories is accidental. With namespace packages foo.bar and foo.baz might live on totally separate parts of the filesystem. They might not live on the filesystem at all and instead be in a zip file. somedir/ otherdir/ __init__.py foo.py scripts/ __init__.py myscript.py # in myscript.py from .. import otherdir.foo If you `python scripts/myscript.py` then it won't work because myscript.py is run with a __name__ of __main__ which doesn't have any parent module. When you run python -m scripts.myscript it sets __package__ to scripts.myscript so now it does have a parent module and somedir and otherdir are importable under the root module because '.' is added to the search path by default.

BurningFrog 2y ago

The worst thing is that it can't handle circular imports, unlike every other language, AFAIK. I've been told it's because of some deep part of Python interpretation that just can't be changed. The mutable default argument madness is also caused by that. Anyone know more?

aeturnum 2y ago
My guess is that imports in python are just executing python. When you import a module you are (optionally) running code in that module. So a circular import generates infinite recursion. Python does a lot when it evaluates an import statement. That is where a lot of the python magic happens. As soon as you try to limit the import statement somehow, a lot of python code needs to be re-written (and maybe doesn't work at all anymore). That's arguably a bad decision but it's one at the center of the language and it's unlikely to change.
- augusto-moura 2y ago
  Exactly, importing (like everything else in Python) is just a "syntax sugar" around loading the code on a file and running it instantly. If you do a circular reference it can pop the stack
  - dmurray 2y ago
    > importing (like everything else in Python) is just a "syntax sugar" around loading the code on a file and running it instantly. Not quite - it also checks whether the file has already been imported, and does nothing if so. And it also checks if the file has been "partially imported" which is what causes it to fail during circular imports. You could imagine a small change to Python which made the second case a no-op as well. This would allow you to use circular imports. You'd need to restrict yourself to imports like "import mymodule; mymodule.myfunction()" rather than "from mymodule import myfunction; myfunction()" but that's encouraged in popular style guides [0] anyway. By the time you run the function, mymodule.myfunction will be bound correctly and everything will work. This would create hard-to-debug situations for people who rely on executing lots of side-effect code to set up state at import time, but 1) that would only happen in code that currently can't run at all, and 2) those people deserve it. I think it would even be reasonable to make the "from mymodule" version work by binding those names later, but it wouldn't be a one-line change to the interpreter and it might break some legitimate use cases where a name got redefined. [0] https://google.github.io/styleguide/pyguide.html https://google.github.io/styleguide/pyguide.html