I personally prefer consistency (e.g. I dislike the Scripts/bin dichotomy and I don’t want to exacerbate the situation).
It’s as “well accepted” as any single name from what I can tell (it’s either “venv” or “.venv”). I used to suggest “venv”, but personal experience caused me to change my mind and I haven’t regretted the switch. But it’s personal experience and everyone will have reasons for choosing the default that they choose.
I just realized that git kind of burst this bubble for everyone. In the Python community, it would not be shocking for a project to have some combination of:
.git.tox.nox.github.flake8etc. in their project directory. So while OS support might not be universal, I don’t think the concept of something on the file system with a leading . is something that beginners either are not or won’t soon be exposed to regardless of whether virtual environment directory names use them.
I totally agree there – that is horrid. I will completely support consistency over different standards for different platforms.
I doni’t know that we should follow git’s lead – that’s a Unix-y tool if there ever was one – but a number of the others are getting to be Python standards.
Perhaps ironically, I think Windows users are fine with dotfiles – they don’t get hidden, but look a little weird/special – that’s a good UI,
You’re aware that Microsoft switched all their internal version control to git? It might have a unix-y genesis, but it’s surely got one of the highest cross-platform penetrations of any program these days. It’s IMO a very convincing argument that dotfiles are everywhere and not going anywhere.
If it’s standardized in a PEP, perhaps it should follow Python’s naming convention: __venv__, following __init__.py, __pycache__, etc.
I prefer __pyvenv__, because it is specific to Python.
Windows was also updated to make it easier to create and work with files starting with a dot (which previously were invalid due to how the 8.3 naming convention worked and was extended into long file names).
In general, Windows is very accommodating when it comes to adopting Unix-y themes. I wouldn’t use OS-level conventions as an argument for/against .venv (though I think Python’s __naming__ convention is a worthwhile argument against dot names).
Hmm, that’s a reasonable argument, and I hate it 
I find double-underscore filenames (especially directories, with no extension) ugly, and I’ve become both accustomed to, and happy with, the .venv convention. But following the Python convention has some merit. On the downside, __venv__ is harder to type (needs a shift on a PC keyboard, and a mode change on mobile).
Is there any established practice of doing __venv__? I don’t believe so and it’s IMO better to settle on one of the existing names rather than adding one-more-way of doing things,
No, but also, it’s a naming convention that is explicitly reserved for standard Python stuff. Anyone who looked into whether they ought to do it would probably decide that they shouldn’t, even if they thought it was appropriate.
When I asked on Twitter back when I was trying to figure out if there was any common practice, some suggested it but it definitely never came up as an “established practice” or something people were regularly doing compared to .venv or venv.
I have mixed feelings for __venv__.
On the one hand, if you want an official convention, it is a very good way to communicate that “this is how it should be done” and make it feel it has an “official” branding (since people recommend you shouldn’t invent your own dunder names).
On the other hand, the precedent __pycache__ is for something that you should never touch yourself. __venv__ gives me a bit of an impression that it’s something magic that happens behind the scenes and which I should just ignore in most cases. I guess whether that’s a good thing depends on the degree to which this environment is managed automagically.
VS Code (made by Microsoft) puts it’s project specific files in .vscode
I think __venv__ is ugly. Python is the only language using this convention. I don’t think it’s a good thing. Imagine if C++ had ++stuff++, C# had stuff-###, and so one, each language created it’s own convention.
__venv__ might be consistent with Python, but .venv is more consistent with the world.
Which makes is a good choice for something very specifically Python.
as for adding “yet another option” to current common practice – if trying to establish a new standard, maybe it’s better not to use one of the common ones currently in use.
I’ve filed a PR to withdraw this PEP, as I’d stated earlier.
Thanks for a 
lively discussion on this proposal folks!
It was quite a productive one for getting a better collective understanding of the problem and it served the purpose of bringing forward legitimate concerns with this approach, how pip’s behavior changes interact with other tools, the vast array of workflows/management solutions that people have for virtual environments and other useful discussions on the topics that the PEP affects.