on large sourcetrees this can slow up development so it needs to be enabled by an option ... but it if needs to be manually enabled it is less useful. Pending a solution coming from a more intelligent/configurable filesystem later, what about an import hook that refuses to load anything from a .pyc where no .py is present? And maybe optionally disable the installation of this hook? Sounds useful to me - not sure if it can be done cleanly and robustly considering the python import system complexity.
On a sidenote, if we more naturally and more quickly drive distributed testing to various sub environments (virtualenv etc.) the issue might vanish - because rsyncing can take care to never transfer pyc files.
since py.test -f tracks changes on the tree, it should be able to remove the .pyc which lack a .py file
collect is another thing that could be enabled to deal with missing .pyc files
but the import hook sounds valid, too
I don't think py.test should ever delete files in a tree. Even if they are likely compiled junk, there's no guarantee that someone is not storing their passwords (or worse) in it. Simply refusing to run tests where only a .pyc file exists is much more optimal behavior.
its not about test modules, its about random modules still seemingly working after the py file is in another place already