Hacker News Reader

Hacker News

Comment by e-dant | Hacker News Reader

Parent Full thread

e-dant

I hate init py files the same way I hate Java’s verbosity.

If it looks like a package, it’s a package.

If I want to be explicit, I’ll write something in C.

View on HN

There's nothing better than verbosity on large projects, especially in rarely-touched areas (build/test/deploy infra).

The perfect anti-pattern example is sbt. It shortened commands to unintelligible codes, even though you need to write it maybe once per year.

And by the way, you never write full lines anyway, autocomplete knows what to write using just 2-3 keystrokes, even without any AI. So verbosity doesn't affect writing speed anyway.

> If I want to be explicit, I’ll write something in C.

Absolutely love those explicit void pointers.

The problem is that packages can also look very different. For example, Python can import an entire package hierarchy from a zip file. (This is essential to how `zipapp` works; and under limited circumstances, a wheel file can also be used this way - which plays an essential role in how Pip is bootstrapped.)

> For example, Python can import an entire package hierarchy from a zip file.

As could Python's contemporaries back in the day, JAR extensions notwithstanding. That fact does not justify bad design.

__init__.py distinguishes (for the import machinery as well as human readers) standard packages from implicit namespace packages, both of which "look like" (and are!) packages.

Fwiw, I never use them in Python if I don't need to put anything inside them. They're optional for a reason.

They are "optional" because support was added for implicit namespace packages, but those have different semantics (particularly, placing another thing that resolves as a namespace package with the same name elsewhere on sys.path adds to the same package; as a result, the import machinery can't stop scanning sys.path when it finds a namespace package, it has to continue scanninng to see if there are more parts to add or if there is a standard package that takes precedence, so leaving off __init__.py for what is intended as a standard package, as well as opening up potentially incorrect behavior, adds a startup cost.)

Reply on news.ycombinator.com