If the community is going to standardize on .venv as the default name, we should ask virtualenv to update their docs. They currently use venv as the default:
Another place I’ve seen venv instead of .venv is we could also ask PyCharm to change their default (when it’s not already using a workflow tool such as Poetry):
I suspect PyCharm would do this if there was an accepted PEP that decreed this.
Why not just raise a request/PR asking them to change? If they refuse, asking them what it would take to change their minds would be a useful way of determining what needs to happen next.
Possibly/probably, but we would need to get .venv written down as the “official” recommendation first.
I wonder about .venv for newbies.
“dotfiles”, are (I"m pretty sure) hidden by default on all *nix and Macs, and shown by default on Windows.
Most *nix users will expect this, but Mac users might get pretty confused.
Newbies have enough trouble with Windows hiding the filename extension by default 
Yes, and for Windows users. The “dotfile” convention is very unixy-centric. I don’t really use venv so I’m not sure, but it does sound like .venv is kind of standard already.
I’m not really happy with the wording in “Opting out of virtual environments”. it MUST provide an opt-out. What if if you are installing an OS package globally (let’s say something like youtube-dl, Graphor, etc…) ? What if I don’t want to use VE at all?
Since VS Code adopted it we have not run into any confusion or concerns from beginners, just advanced users being concerned for beginners (and that’s a serious comment; we have gotten way more complaints from advanced users wanting to search their virtual environment for some code and having some tool ignore . stuff by default). I suspect most beginners don’t even think about it being some convention or question it; to them I suspect it’s “just how things are,” and move on; they are just following the instructions. I also think you’re assuming beginners are doing raw terminal work and not some tool which will show things differently than e.g. the Finder in macOS, and once again, with no instructions on e.g. activation next or something else they are going to just blindly type in the terminal.
Honestly, the much bigger problems for beginners are putting their code in their virtual environment or committing it to version control (which is why VS Code’s Create Environment command drops a .gitignore file in the virtual environment directory).
I’m not assuming that, but I’m a bit confused – the Finder in OS-X hides dotfiles by default. I think that’s a greater potential source of confusion than Windows, where, IUUC, there’s nothing special about dotfiles. This is no different than, say a __init__.py file being something special.
Are you suggesting that folks don’t use Finder for looking at their projects?
It’s a bit of a tangent, but I often wish that pip install had a --local switch akin to --user that installed packages into __pypackages__, say, in the local folder. This local installation would be lightweight and completely transparent, without explicit activation, and would work on top of venv, conda, etc. As such, it would be part of the import system in Python rather than any specific package manager.
In the spirit of this PEP, if global installation is impossible, e.g. because of EXTERNALLY-MANAGED, then pip could say: “You can install packages locally into the current folder using pip install --local.” This would not elevate venv or any other tool above any others.
Ideally, the local install would keep a list of installed packages that can be committed, as well as the actual binaries separated by Python ABI, so that you can just reinstall the local packages with some command should you switch machines or Python version.
Is pip install -t __pypackages__ foo not sufficient? That can be
aliased to something else rather trivially if it’s too much to type.
Remember that pip can install packages anywhere now, and into any
existing Python environment too, like:
python3 -m venv __pypackages__
pip --python __pypackages__/bin/python3 install foo
No activation is required to do that.
The installation isn’t so much the problem as that i) it should be picked up automatically as the first path by importlib, and ii) it should be organised such that the list of local packages is separated from the installations of said packages, because of committing, relocating, etc. But maybe both are easily doable nowadays?
Well, now you’re asking for default behavior changes to the Python
interpreter, not pip. Different stakeholders with a different
process for requesting and agreeing on behavior changes. That’s
where the aforementioned PEP discussions come into play.
Not “don’t”, but not “always” either. As I said, I have never had someone talk to me about some struggles a beginner had from a virtual environment being named .venv and it being hidden by default on macOS (or any other OS).
Good to hear – we need to learn from actual experience. For my part, when I’ve taught (or tried to) virtual environments, beginners have found the whole thing confusion – so can’t say a possibly hidden directory name has or hasn’t been a contributor to that confusion.
But why? dotifles are a convention in the *nix world, but only that world. If it’s a well accepted convention already then sure, but from this thread I’m not sure that’s the case.
It would have to print an explicit message telling the user that .venv is chosen as the virtual environment directory, then. Nothing worse than having a command silently succeed without knowing what it did.
Yes, many users coming from other operating system paradigms are
often confused when they run a command and get no output, thinking
it means something is wrong. For those of us who have used Unix and
its derivatives and clones for decades, we assume no output means
success and if a trivial command displays something then it’s
probably alerting the user to an error. This has (unfortunately in
my opinion) slowly eroded as developers who started in other
ecosystems begin to port software and print lots of unnecessary
information, forcing the user to add a --quiet option to commands
or, worse, redirect standard output and maybe even standard error to
a null sink in order to just make them shut up, or pipe them through
complex patter-matching filters in order to get rid of all the noise
without missing actual errors that get mixed in.
For the same reasons, I much prefer dotfiles and dotdirs for storing
“unimportant” data, leaving only important-to-me directories in my
listings (where my documents reside, directories in my default
executable path, and so on). If I want to list the unimportant
ones too, there’s a non-default command line option I can supply to
see them. I get the impression I’m not alone in that sentiment,
though it seems increasingly likely we may be part of an aging
population that values silence, focus, minimalism, and lack of
distraction… and that people are more recently being trained to
prefer noise and constant validation. Overarching software design
paradigms certainly seem to be changing in ways that make things
less usable for me, but that may very well mean I’m the problem. 
Unix tools have their idiosyncracies, but Python is not part of Unix/POSIX proper, and the world has changed since POSIX was introduced. I think that tools that are meant for mass adoption should be more verbose, friendly, and informative, to help users understand what’s happening, Unix tradition be damned. pip install requests produces 17 lines of output in a clean environment. git init produces one line. I think that python -m venv should produce at least one confirmation line too. Possibly more, so that the users know that the tool is busy creating the venv and installing things into it (as it takes a few seconds, especially on slower hardware).
Dotfiles were a bit of a hack in early Unix. They are more of an official thing now, but if you are making tools, please don’t clutter my home directory with your stuff (dotfiles or not), but instead put it in the appropriate configuration directory (~/.config on Linux/XDG, ~/Library on macOS, and ~\AppData on Windows).