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.
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).
Did I just make that up?