Idea: filename structure

[innicoder]

Filename suggestion

Filenames inside the app/module specific can be example: {module}_service.py. At some point it would be nice to create a generator for these like in django. django startapp auth.

Reason

We are already importing them from src.auth import constants as auth_constants it is easier to just change the filename so we don't have to keep track and it doesn't create any conflicts.

PR - https://github.com/zhanymkanov/fastapi-best-practices/pull/12

Example

[zhanymkanov]

Hey, @innicoder, thank you for your proposal.

I believe it's not a great idea to duplicate the name of the package in the module's name, since we should assume that everything in that package is defacto related to that package and hereby doesn't need an explicit prefix of the package.

Importing the neighboring module within the package is the most frequent thing we would do, e.g. in the auth's router module we regularly use functions from the auth's service module. That would be unnecessary to call modules with an auth prefix since in the auth.router we mostly expect auth.service and nothing else. Having a longer name is redundant here.

But, if we have to import service from another package (which is a less probable thing to do since we try to keep packages loosely coupled), we would have to name it with an explicit package prefix.

[innicoder]

I understand, however, most or the time this naming convention makes sense and it's really simple.

To add to that it also doesn't make anything worse.

To play the other side, the most common use case is that we use from packace import x

This is the proper convetion rather than using import x, ok I have no problem with that, this suggestion came from my experience.

Readability matters and usage matters, sometimes it's better that things repeat for structure and readability and ease of use.

I'm however happy that you considered it and if sometime in the future you see the need, you can just add it.

Thanks again for your time and efforts.

[innicoder]

Hey, @innicoder, thank you for your proposal.

I believe it's not a great idea to duplicate the name of the package in the module's name, since we should assume that everything in that package is defacto related to that package and hereby doesn't need an explicit prefix of the package.

Importing the neighboring module within the package is the most frequent thing we would do, e.g. in the auth's router module we regularly use functions from the auth's service module. That would be unnecessary to call modules with an auth prefix since in the auth.router we mostly expect auth.service and nothing else. Having a longer name is redundant here.

But, if we have to import service from another package (which is a less probable thing to do since we try to keep packages loosely coupled), we would have to name it with an explicit package prefix.

I and my fellow colleagues that I have shown this repository have gotten great benefits from your work, the best thing it's that it's written in a simple manner, without overhead or overwhelming. Easy to understand and implement.