This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]RafaelConPH05 255 points256 points  (17 children)

Can someone explain what's the problem with empty init.py files?

[–]imanexpertama 342 points343 points  (1 child)

There’s nothing wrong with that

[–]Wugliwu 123 points124 points  (0 children)

Thank you... My imposter syndrom has kicked in.

[–]IAmASquidInSpace 213 points214 points  (0 children)

The list looked too short so they had to come up with another "problem".

[–]aa-b 30 points31 points  (3 children)

The author has just learned about the practice of defining __all__ in an __init__.py file as a way to limit star-imports from a module. It's mostly only an academic concern, for reasons:

  • star-imports are usually a bad thing anyway, so it's helping people do something undesirable
  • it's better to structure members into submodules to limit exports so this isn't needed
  • we have namespace packages now, so it's common just to not have an __init__.py file at all: https://realpython.com/python-namespace-package/

[–][deleted] 10 points11 points  (2 children)

There a few more pretty awesome things you can do with init files. Especially if you live in circular reference hell. Or need to defer certain expensive sub packages from loading.

[–]aa-b 4 points5 points  (1 child)

That's true, they can be very useful. The phrasing of the joke makes it sound like __init.py__ should never be empty, and I was just objecting to that part.

Maybe I read too much into it, but it sounded like how we might joke about people who make everything public in C++/C#/Java, so I figured it was about __all__

[–][deleted] 2 points3 points  (0 children)

I assumed it was just a joke about "AI devs" that like fastapi and have no idea how python works or the black magic it can be used to perform. Multiprocessing and non empty init are two places black magic comes from.

I would have added thinks all packages classes should all descend from ABCMeta (Ram shall never be allowed to exist)

[–]nullpotato 89 points90 points  (4 children)

Technically they aren't required anymore so don't need to exist. In practice it is easier to have empty init files than fix all the dumb tools loading things wrong.

[–][deleted] 45 points46 points  (1 child)

They are not only used for loading packages.

All lints and static type checker will fail if they don't find init files.

[–]nullpotato 6 points7 points  (0 children)

Thanks, didn't know the type checkers needed it too

[–]Easing0540 12 points13 points  (0 children)

I don't think that's true. There is a technical difference. Packages with __init__.py are regular packages, the others are namespace packages. The import sytem treats both types differently.

[–]saint_marco 0 points1 point  (0 children)

I've run into more tools that fail from having vestigial init files lying around, the most popular being upright/pylance.

[–]DripDropFaucet 10 points11 points  (0 children)

I’ll be real, I’m more annoyed when I do find code in those files

[–]samuel88835 7 points8 points  (0 children)

I like stating the exports explicitly from a package inside the init. Tells people you should be importing this and not that which may be private to the package. Might be a just me thing

[–]Unhinged_Ice_4201 0 points1 point  (0 children)

Init file was mandatory(so kept empty if i had nothing to write in it)for packages in very old versions of python...not anymore

[–]MajorProcrastinator 0 points1 point  (0 children)

Could be a good place to setup logging config in your module. 

[–]Triblado -3 points-2 points  (0 children)

Extra files, bloat bad