Not sure if this is the best solution to the problem as it inlines the prompt creation, creating two places where the default prompt is specified. There's also missing doc updates and it isn't using f-strings.

But before you attempt to fix this, @mental32 , please wait a day to see if I come up with a solution for https://bugs.python.org/issue37663 which might make this change a moot point (and if I do I will flag it to you for a review).

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

That's fine, thanks for reviewing!

Hopefully you find a better solution with 37663.

I do have a couple of questions:

• you mentioned a doc update but this looked like a minor patch that broke expected behavior so I assumed it needed nothing more than a news entry, could you expand on that a little?
• while I adore them, I didn't use f-strings on purpose, I was conforming to the rest of the source file's apparent style, should I always make pep8 changes when proposing patches? and if so pep8 has a section on consistency is this the case guido had in mind when the section was written?
  • shouldn't effective cosmetic changes be addressed on a larger module bases with a separate PR?
• regarding my etiquette how did I come across? was I too abrasive, you mentioned I should wait a day? basically how could I improve the way I come across when discovering issues if you see anything I could improve upon.

Thanks for bearing with me, it's very obvious I'm new and nervous but I find the best solution is if I question everything and constantly look to improve, that way end up messing up less often :)

@mental32 Happy to answer the questions!

1. You introduced __VENV_DEFAULT_PROMPT__ and all of the substituted strings are documented in the venv docs.
2. So consistency from a PEP 8 perspective is things like whitespace formatting, docstring style, etc., not what parts of Python you can use (especially in a case like this where it won't affect the public API and thus the feel of the module). And you can update code that you happen to be editing, but you shouldn't do a mass-file update, e.g. if you were touching code that used % you could totally switch to f-strings, but don't go through the whole file and do a mass switch. Or if you want a rule of thumb, if git blame won't change who made the last change for a line you're already changing then you can do what you want.
3. You came across great! I only said "wait a day" because if I can't get my act together and get a patch up with my proposed cleanup I don't want to block you from contributing and helping fix stuff (basically it's the last day of Hackathon week at work and I'm set up already to test all 5 shell scripts, so I can conveniently try to make a sweeping change today only 😄 ).

Ah bully!

Thanks for answering my questions, It cleared up a lot for me. I'll revise the documentation thoroughly next time I make a change to a modules public API and I can't help but think that your second answer, regarding style, could be inserted as a note in the developer guide.

Hope you enjoy your hackathon and in the meanwhile I'll be eagerly stalking the bpo :D

(I'll close the PR with this comment since I assume you'll have a neater solution lined up later on).