Hacker News new | ask | show | jobs
by simonw 681 days 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.

3 comments

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/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.
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

> 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.
also when you were a beginner python imports were much simpler than they are now
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.
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.

> 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.