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

1 comments

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