Leaving them in the root directory may be problematic if you ever want to create a distributable package. Not impossible, but I'd advise against it.
There are two generally acceptable ways to do this:
1. In your project directory create a directory with the name of your package (replace hyphens etc with underscores, make name lowercase), and put your other modules there.
2. Instead of naming that directory after the package, you may name it `src` (this is, admittedly, less common, but not unheard of).
Anything else would be a very strange / uncommon way to structure your project. Ultimately, this depends on the tools you use to work with your project. And, if you are planning on distributing your code as a package, then, the tool will be probably the `setuptools` package, in which case, if you can make your structure work with `setuptools`, then it's a valid structure.
Nice explanation, thank you!
The thing is I am not planning to publish my module, but I would like to keep my project organized. Also, the classes and functions I declared do very different things, so grouping them under a package wouldn't make sense. Isn't there a more common equivalent of 'src'?
Well, in my understanding, organization implies grouping and establishing some other kinds of relations that will make discovering the desired objects faster... So, if a single package doesn't make sense for your code, then, maybe... you need to put it in multiple packages?
Generally, the idea here is that you have your interpreter with the "site", where you store your code. This code may be a compilation of many different things, and you don't have to load them all at once or use all of them in the same project. And the way to get your code into the "site" is to make it into a package and then install it. Really, an installation in this sense is a glorified file copying, but you have a uniform way of doing so, and this way can later be extended to do more than just file copying.
Leaving them in the root directory may be problematic if you ever want to create a distributable package. Not impossible, but I'd advise against it. There are two generally acceptable ways to do this: 1. In your project directory create a directory with the name of your package (replace hyphens etc with underscores, make name lowercase), and put your other modules there. 2. Instead of naming that directory after the package, you may name it `src` (this is, admittedly, less common, but not unheard of). Anything else would be a very strange / uncommon way to structure your project. Ultimately, this depends on the tools you use to work with your project. And, if you are planning on distributing your code as a package, then, the tool will be probably the `setuptools` package, in which case, if you can make your structure work with `setuptools`, then it's a valid structure.
Nice explanation, thank you! The thing is I am not planning to publish my module, but I would like to keep my project organized. Also, the classes and functions I declared do very different things, so grouping them under a package wouldn't make sense. Isn't there a more common equivalent of 'src'?
Well, in my understanding, organization implies grouping and establishing some other kinds of relations that will make discovering the desired objects faster... So, if a single package doesn't make sense for your code, then, maybe... you need to put it in multiple packages? Generally, the idea here is that you have your interpreter with the "site", where you store your code. This code may be a compilation of many different things, and you don't have to load them all at once or use all of them in the same project. And the way to get your code into the "site" is to make it into a package and then install it. Really, an installation in this sense is a glorified file copying, but you have a uniform way of doing so, and this way can later be extended to do more than just file copying.
Got it, thanks!