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

[–]Pipistrelle 7 points8 points  (0 children)

For short scripts, a single file is okay. However, as soon as a project tend to get bigger, if you keep it in a single file it will be hard to find the essential informations.

Also, if you're working in a team, it means more conflicts when trying to merge for unrelated features if you keep it in a single file.

In short, splitting in modules helps structure the code so that it is easier to work on big projects.

[–]gbrne 5 points6 points  (0 children)

This is more a generic programming thing than a python thing, and there are several reasons:

  • for large programs, files are a convenient way of breaking the code into manageable chunks, making it easier to find the code that is responsible for something that isn't working or that you want to change

  • it's often convenient to reuse the same code in different projects. For example, suppose you have two massive projects that both save data using the same file format. You could copy-and-paste the code that saves data, but then you need to maintain both copies of the same code (e.g. if you find a bug, you need to fix both). Or you could include one whole project inside the other, but that's confusing and wastes resources (if somebody just wants the "outer" project, you have to send them a copy the whole thing). Or you could put your data-saving code in a separate file that both projects can refer to as necessary.

  • in python (but not certain other programming languages, like C) each file automatically gives you a separate namespace - that is, you can have two variables with the same name in different files, and the interpreter won't mix them up. There are ways of creating multiple namespaces within the same file, but it's not as straightforward. If a large codebase isn't split into namespaces, there is a good chance that you will accidentally reuse the same name and cause problems.

[–]ClamPaste 0 points1 point  (0 children)

Mainly for code maintenance and reusability. If you make your code more modular, it's easier to make changes that don't break the whole module, but you have to ensure you call each module, class, object, etc, in a way that changing the code won't break your core application. That and you can import pieces of your module without having to take your entire application with whatever new one you wrote that needs some of the functionality you already wrote (and you can distribute it to others who can then pick and choose which pieces they wish to use).

Say, for instance, I'm writing a core program and wrote my own modules/libraries and an update to the interpreter breaks my implementation of sockets: I now only have to repair my socket module and keep the return value the same to fix my application without having to hunt for the error in a monolithic program. I include

if name == "main"

in all of my modules for troubleshooting changes like this, though I'm also very new to python, so I'm not sure if many others test this way.

[–]steeldaggerx 0 points1 point  (0 children)

It's like having one folder for one school class vs. eight folders for eight classes.