How is the project structure in python?

If you are going to use the "pure" python structure the way you want it, including the way you did in your previous language, of course, adapting to the particularities of python. Now ... if using a framework such as django or flask, it would be ideal to follow the recommendations of the FW developers.

Suggestion of one of the members of the Python Software Foundation to design pure python project repositories:

README.rst
LICENSE
setup.py
requirements.txt
sample/__init__.py
sample/core.py
sample/helpers.py
docs/conf.py
docs/index.rst
tests/test_basic.py
tests/test_advanced.py

See more details on the author's website.

Most widely praised practices in the python community are those recommended by the twelve-factor,

The twelve-factor app:
In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor application is a methodology for building software-as-a-service that:

• Use declarative formats to automate initial setup, minimize time and cost for new developers to participate in the project;
• It has a clear contract with the operating system that supports it, offering maximum portability between environments that execute it;
• Are suitable for deploying on modern cloud platforms, avoiding the need for servers and system administration;
• Minimize the divergence between development and production, allowing continuous deployment for maximum agility;
• And can scale without significant changes in tools, architectures, or development practices. The twelve-factor methodology can be applied to applications written in any programming language, and using any combination of media services (database, queues, memory cache, etc.).

I do not know if there is a standard for this type of division, I even consulted the PEP but I did not find anything related. But it follows the pattern I use to build my projects based on this article ( Filesystem structure of a Python project ):

Projeto/
     NOME/
        __init__.py
        controllers/
            __init__.py
        views/
            __init__.py
        models/
            __init__.py         
     bin/
     docs/
     setup.py
     testes/
         NOME_testes.py
         __init__.py

You can also build on the structure of some larger projects, following the structure of Django ( Skeleton Django Project )

[projectname]/                  <- project root
+-- [projectname]/              <- Django root
¦   +-- __init__.py
¦   +-- settings/
¦   ¦   +-- common.py
¦   ¦   +-- dev.py
¦   ¦   +-- djangodefault.py
¦   ¦   +-- __init__.py
¦   ¦   +-- production.py
¦   +-- urls.py
¦   +-- wsgi.py
+-- apps/
¦   +-- __init__.py
+-- configs/
¦   +-- apache2_vhost.sample
¦   +-- README
+-- doc/
¦   +-- Makefile
¦   +-- source/
¦       +-- *snap*
+-- manage.py
+-- README.rst
+-- run/
¦   +-- media/
¦   ¦   +-- README
¦   +-- README
¦   +-- static/
¦       +-- README
+-- static/
¦   +-- README
+-- templates/
    +-- README

Dude, I usually use a framework of my own. In a crud with graphical interface with three tables: A B C I usually do:

* A folder for A with the crud file, the main py file and the graphical interface

* A folder for B with the raw file, the main py file and the graphical interface

* A folder for C with the raw file, the main py file and the graphical interface

* The main page files (the main py and the graphical interface) in the main folder.

It works, but it varies from the graphical interface of the SQL language.