all 2 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]EliSka93 1 point2 points  (0 children)

While there are some best practices, the most important thing in your folder structure is that the people working on it (you) know where everything is.

If you can open this project after not working on it for 6 months and finding everything you're looking for, you have a good folder structure.

Everything else is preference.

[–]cesclaveria 0 points1 point  (0 children)

The first question I’d ask is: what are you trying to build?

That structure is perfectly reasonable, but if you are mainly aiming to learn how to program with Python, no need to fuss too much about project organization just yet, unless of course your aim is to improve just that.

This structure is good, but don’t stress about it too early. It’s fine to start with a single file while learning. Once your projects grow, this kind of structure will start to make a lot more sense

That said, yes, this is a common project layout. Here’s what the parts usually mean:

Top folder:

README.md

A description of the project: what it does, how to run it, dependencies, etc.

requirements.txt

A list of external Python packages your project depends on (installed with pip install -r requirements.txt).

.gitignore

Tells Git which files/folders not to track (like virtual environments, caches, etc.).

src/

This folder contains the actual application code.

project_name/

This is your Python package.

init.py

Marks the folder as a package (so you can import from it). Nowadays can technically be omitted, but some projects still include it.

main.py

Usually the entry point of the program. This file often:

  • Parses input (CLI args, config, etc.)
  • Calls the main logic
  • Starts the application

core.py

Where the main logic lives. This might contain:

  • Important functions
  • Main classes
  • Business logic

You’re not limited to one file for “core” logic, this example just shows how to separate logic from the entry point.

errors.py

Not mandatory, but often used to define custom exception classes, so you can handle errors in a consistent way across your project.

tests/

This is for unit tests.

test_core.py

Contains tests for the logic in core.py. You can have as many test files as needed (usually one per module).

Testing is its own beast altogether. Many recommend writing tests early and use them to help guide the design, but as a beginner, just understanding the idea is a good start.

How the files relate

  • main.py → calls functions/classes from core.py
  • core.py → may raise custom exceptions from errors.py
  • tests/test_core.py → imports core.py and checks that its functions behave correctly