I totally agree - having no standards around common problems (like how to deal with tests once they get too big for a single tests.py) is extremely inconvenient.
That's because Django, while monolithic, is in many ways based on pythonic principles.
In Ruby, for instance, you really need conventions as in Ruby the concept of packages and how they get included / used is a lot more relaxed.
In Python tests.py is a package as far as Python is concerned. If it gets too big you can make it a directory and break its contents in several sub-packages. I did this with everything else too, like views.py or models.py
The one concept Django has that I consider a flaw is in fact non-pythonic - apps. That's because apps are not just simple packages. Instead apps are packages that have to be specified in an INSTALLED_APPS constant in a top-level "settings" package. This makes using parts of Django in scripts a PITA, as your script needs an accompanying settings file. Also, apps are not properly defined either and in some instances an app must have a "models" subpackage (or at least this used to be the case).
In Ruby, for instance, you really need conventions as in Ruby the concept of packages and how they get included / used is a lot more relaxed.
In Python tests.py is a package as far as Python is concerned. If it gets too big you can make it a directory and break its contents in several sub-packages. I did this with everything else too, like views.py or models.py
The one concept Django has that I consider a flaw is in fact non-pythonic - apps. That's because apps are not just simple packages. Instead apps are packages that have to be specified in an INSTALLED_APPS constant in a top-level "settings" package. This makes using parts of Django in scripts a PITA, as your script needs an accompanying settings file. Also, apps are not properly defined either and in some instances an app must have a "models" subpackage (or at least this used to be the case).