Hacker News Reader

Comment by remram | Hacker News Reader

Preferably enforce that the namespace matches the include/import statement, if the statement doesn't use an explicit name binding...

import "foo/bar" should make foo.* OR bar.* available, not bazz.*. I'm looking at you, Go.

View on HN

Python has this in a slightly different spot. Most pypi packages have the name and module aligned but it’s only a matter of convention, and there are some common deviations like the pyyaml package providing the yaml module.

Ah yes, Python's package manager has it wrong also. But at least Python the language is clear, so you can know "import foo" or "from bar import foo" creates a name "foo" in your file. Go has no such limitation. Imagine doing "import pyyaml" and "yaml" is the name defined...

Wait I’m so confused by this - this is the opposite of how I thought it worked? Go import creates exactly the symbol you mention in the import statement, like “import fmt” creates a symbol “fmt”?

Can you give an example of what you mean?

Yea, this is correct.

    ```go
    import (
       "net/http"
       "os"

       "github.com/anacrolix/torrent"
       tstor "github.com/anacrolix/torrent/storage"
    )

```

would import as: http, os, torrent and tstor. That guy is mixed up.

I don't know what this proves. See example above for an example of exactly what I've said.

The only example I have in mind is modules, which can have a different name from their root package.

For example you can have github.com/user/go-module as module name, and "module" as package name, so "import github.com/user/go-module" will be imported as "module.*".

There’s a linter that automatically aliases this kind of imports with their actual module name so that it’s non ambiguous when reading the import list.

Here's an example, a package bar under a totally different name:

    package main

    // imports 'bar', you couldn't possibly know from reading this line
    import "github.com/remram44/foo20240527"

    func main() {
        // ??? where does this function come from ???
        bar.SomeFunc()
    }

> I'm looking at you, Go.

I’m so confused by this. Unless you use a dot import, isn’t this just bar.*?

I'm not sure what you mean. The name binding created is whatever `package <...>` is in the target package's file, which can be anything.

Ah got it. I think there’s such a strong convention there, that it would be exceedingly rare to see in pratice. It’s probably allowed just for compat reasons at this point — but I think your point is don’t make that mistake in the first place, not that Go is filled with flagrant violations of the convention.

This is normally how it works, no?

What does that mean?

it means: this is normally how imports in Go work, is it not?

What is how it works? How is it normal?

I posted a criticism of Go, I don't know what you mean by "this is how it normally works".

I'm saying that when I import something, "foo/bar" "bar/baz" etc, The way I access the exposed functions and types in that package usually corresponds to the basename. e.g. bar.* for the first example, and baz.* for the second example. Is your criticism of Go that it is technically not required for this to be the case?

Reply on news.ycombinator.com