Ross Boylan <ross.boy...@ucsf.edu> added the comment: As someone who finds the current behavior surprising, and having lost significant time because of it, I have a couple of comments.
1) If the venv created a python3 (or 2, as appropriate) file, would the expected behavior with !#/usr/bin/env python3 be restored? I think the previous analysis said that python3 doesn't match the venv because there is no python3 in the venv path. So putting one there would fix it. Of course, it would only help for newly created venvs. The pythonN file would need to be in addition to the python file, not instead of it, so that invocations of python without a number continued to work as expected. 2) There appear to be two separate sections of the documentation which govern this case. 3.7.1.2 of Python Setup and Usage says "If the launcher is run with no explicit Python version specification, and a virtual environment (created with the standard library venv module or the external virtualenv tool) active, the launcher will run the virtual environment’s interpreter rather than the global one. " If py myscript.py is invoked that seems to fit this case, but obviously that's not what's happening. I realize one could interpret the python3 in the shebang as an "explicit version specification", but a) that's not on the command line, which seems the more natural reading and b) it's only a partial specification, since it doesn't say which python3 to use. Then section 3.7.2 is about !# lines. So if you invoke py without a version specifier, but the invoked file has a !#, does 3.7.1.2 or 3.2 apply? ---------- nosy: +rossb _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38999> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
