The only reason to call py_compile is to get byte code.  Honoring PYTHONDONTWRITEBYTECODE would, IMO, be a bug, at least according to its documentation (by implication, it isn't explicit about it, and perhaps it should be).

Your use case could be added as a feature by adding a command line option to py_compile, but that would be 3.6 only.

On the other hand, you can achieve your use case via the following:

    python -B -c 'import $MYFILE'

(without the '.py' on the end, obviously).

which is actually shorter, so at first I was inclined to just reject that as unneeded.  (In a Makefile you'd want to CD to the directory or put the directory on the PYTHONPATH, which makes it slightly longer but not much.)

py_compile has an interesting little bug, though: if you pass it a script name, it will happily create an *invalid* .pyc file (eg: python -m py_compile results in a tempcpython-36.pyc file).  compileall on the other hand just ignores files that don't end in .py, which is also a bit odd when the file is named explicitly on the path.  So I suppose that's a bug too.

But absent py_compile's bug, there's no easy way that I know of to "syntax check" a *script* without executing it.  So this is probably a worthwhile enhancement.

Note: if we were designing this from scratch we might decide that honoring -B/PYTHONDONTWRITEBYTECODE was the right way to spell this, but since we are not, I don't think we can change py_compile's behavior in this regard for backward compatibility reasons, so adding an option to py_compile seems the best course.