[RFC] Python3 Timeline

[tqchen]

We plan to do some improvements to the IR in this release cycle, and one such question that comes up is the dependency on python version. Up until now, TVM has always been compatible to both python2 and python3. However, there are language features in python3 that we like, in particular:

• Type annotations like def myfunc(x:int) -> int introduced python3.5
• Class type annotations that decorate fields are introduced python3.6

Introducing these type annotations to the code will make the program cleaner, but that also means the code will not be python2 compatible. If we introduce class type annotation, we can only use python3.6. One of the major benefits is that adopting type annotation allows the introduction of typed DSLs

Some of the options are:

• Keep support python2
• For a new set of features, require python3.5+
• Enforce python3.6

For background, currently, ubuntu support(14.04 python3.4, 16.04 python3.5, 18.04 python3.6). Most packages plan to stop supporting python2 on 2019

[tqchen]

cc @dmlc/tvm-team

[nhynes]

+1 for python3.6

• Amazon Linux 2 and Homebrew (macOS) are on 3.7
• Ubuntu 18.04 LTS is on 3.6
• the EPEL contains python 3.6

In terms of package support, the ones TVM requires (numpy and decorator) already support 3.7. Even pypy nightly has 3.6 support!

also f-strings are pretty okay :)

[yzhliu]

FYI https://python3statement.org/

I tend to have a conservative timeline. Python2 is still installed by default in most Linux distro, supporting py2 is friendly to those just want to have a try. And I'm not sure how many enterprise users are stuck on py2 at the moment.

[nhynes]

FWIW, TVM de facto requires LLVM 4+ for CPU support, but LLVM isn't in any of the current distros. Python compiles much faster than LLVM, so I wouldn't take what's in the default repos to be a constraint.

[tmoreau89]

+1 for 3.6, it seems like the way forward. We already test script compatibility in integration tests right?

[yzhliu]

Another option is to keep runtime apis compatible with py2, so that enterprise users won't face problems integrating tvm into their serving pipeline.

[masahi]

Dropping py2 completely seems too aggressive to me. I often see error logs on the discussion forum where people are still using python 2.7.

So I'm +1 for requiring py3 for new features only for now. In the meantime, we should encourage users to switch to py3, in the next release note for example.

[tqchen]

The conclusion seems to be we should always enforce py2 compatibility for the runtime. We might consider requiring py3 for new features

[FrozenGene]

+1 For a new set of features, require python3.5+. Enforce python3.6 is too aggressive. Many Linux distro are Python 3.5.

[zhreshold]

+1 for 3.5, it's too early to drop 3.5 at this time.

[junrushao]

I am a big fan of python 3.6+, just a question out of curiosity: typed_ast in mypy seems to support python 2.7 as well, using grammar like

some_list = []  # type: List[int]

So what prevents us supporting python 2.7?

Thanks!

[tqchen]

@junrushao1994 I agree that we could use the comment callback for backward compat with 2.7

[tqchen]

this is closed for now, we have decided to keep python2 compact for the new core relay IR