Yep, happens all the time with the standard library. Nowadays, third-party libraries have this issue much less because they can use relative imports except for their dependencies. But the Python standard library, for historical reasons, isn't organized into a package, so it can't do that.

Here's a fun one (this was improved in 3.11, but some other names like `traceback.py` can still reproduce a similar problem):

  /tmp$ touch token.py
  /tmp$ py3.10
  Python 3.10.14 (main, Jun 24 2024, 03:37:47) [GCC 11.4.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> help()
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/opt/python/standard/lib/python3.10/_sitebuiltins.py", line 102, in __call__
      import pydoc
    File "/opt/python/standard/lib/python3.10/pydoc.py", line 62, in <module>
      import inspect
    File "/opt/python/standard/lib/python3.10/inspect.py", line 43, in <module>
      import linecache
    File "/opt/python/standard/lib/python3.10/linecache.py", line 11, in <module>
      import tokenize
    File "/opt/python/standard/lib/python3.10/tokenize.py", line 36, in <module>
      from token import EXACT_TOKEN_TYPES
  ImportError: cannot import name 'EXACT_TOKEN_TYPES' from 'token' (/tmp/token.py)

Related Stack Overflow Q&A (featuring an answer from me): https://stackoverflow.com/questions/36250353

... it's tricky. In Java there's a cultural expectation that you name a package like

  package organization.dns.name.this.and.that;

but real scalability in a module system requires that somebody else packages things up as

  package this.and.that;

and you can make the system look at a particular wheel/jar/whatever and make it visible with a prefix you specify like

  package their.this.and.that;

Programmers seem to hate rigorous namespace systems though. My first year programming Java (before JDK 1.0) the web site that properly documented how to use Java packages was at NASA and you still had people writing Java classes that were in the default package.

But let's all be real here: the ability of __init__.py to do FUCKING ANYTHING IT WANTS is insanity made manifest

I am kind of iffy on golang's import (. "some/packge/for/side-effects") but at least it cannot suddenly mutate GOPATH[0]="/home/jimmy/lol/u/fucked" as one seems to be able to do on the regular with python

I am acutely aware that is (programmer|package|organization|culture)-dependent but the very idea that one can do that drives us rigorous people stark-raving

It took me a while to realize that you do mean __init__.py running when a package imports.

But, you know, top-level code (which can do anything) runs when you import any Python module (the first time), and Python code doesn't have to be in a package to get imported. (The standard library depends on this.)

> Programmers seem to hate rigorous namespace systems though

Pretty much a nothing burger in Rust, so I disagree that items necessarily hate the concept. Maybe others haven’t done a good job with the UX?

That. Forcing people to do it right from day one helps a lot. Also Rust attracts a programmer who is willing to accept some pain up front to save pain later, if your motto is "give me convenience or give me death" you might stick with C or Python.

If you give people an "easy way out" it is very hard to compel them to do it more rigorously. Look at the history of C++ namespaces as well as the non-acceptance of various "Modula" languages and Ada back in the 1980s.

Yeah, that's not exactly the problematic situation... but the good news is I improved the Python's error message for this in 3.13. See https://docs.python.org/3/whatsnew/3.13.html#improved-error-...