Document Python 3.9 support + enable local testing for it

[McSinyx]

Toward GH-8967, before @uranusjr can 😉

• Azure: Add Python 3.9 actions/runner-images#1740
• GHA: Add Python 3.9 support actions/setup-python#148
• Travis: https://travis-ci.community/t/python-3-9-0-build/10091

[pfmoore]

Hmm, why is vendoring explicitly tied to Python 3.8? ping @pradyunsg

[uranusjr]

[error]Version spec 3.9 for architecture x64 did not match any version in Agent.ToolsDirectory.

Hey Azure, you’re late.

[uranusjr]

Looks like they’re working on it Azure/azure-functions-python-worker#753.

[McSinyx]

Travis is late too.

@McSinyx sits back and waits.

[pradyunsg]

Every CI provider will take a while to add these in. That's the usual story around every Python release. :)

Hmm, why is vendoring explicitly tied to Python 3.8? ping @pradyunsg

🤷

I think I'd meant to allow ~= 3.8, soooo... released a fix. :)

[pfmoore]

I think I'd meant to allow ~= 3.8, soooo... released a fix. :)

Congratulations on being careful to exclude Python 4, just in case it's backward incompatible 🙂 Lazy me would have just done >= 3.8... (I had to look up ~= to confirm what it meant!)

[pradyunsg]

Hah. GitHub Actions seems to actually have a good plan for Python releases now. Edited OP to add links to relevant CI providers.

[vrdmr]

@uranusjr FYI - the work being done for in Azure/azure-functions-python-worker#753 is only specific to Azure Functions.
For Azure Devops, the work does is documented in actions/runner-images#1740 (comment)

[pradyunsg]

Suggestion: split out the developer tooling changes into a separate PR, keeping the CI matrix + documentation parts here. That'll let us move forward on the CI as-and-when the providers update, while still letting us do development on Py3.9, as necessary. :)

[McSinyx]

I'll look into it tomorrow, I spent the whole weekend relaxing and now it's late night 😅

[McSinyx]

mypy error makes no sense to me 🤔

mypy.....................................................................Failed
- hook id: mypy
- exit code: 2

src/pip/_internal/commands/debug.py:31: error: syntax error in type comment
    def show_value(name, value):
          ^
src/pip/_internal/commands/debug.py:49: error: syntax error in type comment
    def create_vendor_txt_map():
          ^
src/pip/_internal/commands/debug.py:84: error: syntax error in type comment
    def get_vendor_version_from_module(module_name):
             ^
src/pip/_internal/commands/debug.py:104: error: syntax error in type comment
    def show_actual_vendor_versions(vendor_txt_versions):
     ^
src/pip/_internal/commands/debug.py:201: error: syntax error in type comment
        def run(self, options, args):
             ^
Found 5 errors in 1 file (checked 138 source files)

mypy, for Python 2.......................................................Failed
- hook id: mypy
- exit code: 2

src/pip/_internal/utils/subprocess.py:25: error: syntax error in type comment
    def make_command(*args):
     ^
src/pip/_internal/utils/subprocess.py:43: error: syntax error in type comment
    def format_command_args(args):
     ^
src/pip/_internal/utils/subprocess.py:59: error: syntax error in type comment
    def reveal_command_args(args):
     ^
src/pip/_internal/utils/subprocess.py:69: error: syntax error in type comment
    def make_subprocess_output_error(
    ^
src/pip/_internal/utils/subprocess.py:111: error: syntax error in type comment
    def call_subprocess(
    ^
src/pip/_internal/utils/subprocess.py:256: error: syntax error in type comment
    def runner_with_spinner_message(message):
             ^
src/pip/_internal/utils/subprocess.py:264: error: syntax error in type comment
        def runner(
    ^
Found 7 errors in 1 file (checked 135 source files)

[uranusjr]

python/mypy#8627

tl;dr need to upgarde pre-commit hook to use mypy >= 0.780

[McSinyx]

Thanks, I pinned mypy to 0.790 (the latest release).

[McSinyx]

I think this can be merged now. Edit: 😄 any idea why there are three Travis CI PR builds?

[uranusjr]

Yup. Travis is green, it’s the hook having trouble reporting back (as it often does). The only part I’m not sure about is the change of vendoring specifier from == to >=, I’ll leave this for @pradyunsg to judge since he knows about vendoring best.

[pradyunsg]

One change: