Python3.5 vs Python3.6 Requirement for 0.7

Development pre-RFC
#1

See past discussion for 0.6 cycle [DISCUSS] Require python3.6 vs python 3.5 compatibility

We kept the python 3.5 compatibility for the 0.6 release. This is an RFC to see what shall we do in the 0.7 release cycle. Given that more time shas past and our techinical goals have also changed, we list the new considerations as follows

3.6 Features that could Benefit the Project

There are two features which would be relevant for us f-string and type annotation in class objects. While f-string is more like a sugar that can be replaced in another way. Class object type annotation would be more critical for potential new features we want to develop. In particular, given the first-class python support goal we set, we will likely introduce more python DSLs that involves python AST, parsing. The following snipet gives a possible mock up API that parses a python object definition to define an ADT(which requires 3.6).

@tvm.hybrid.object
class ADTObject:
   field_A : int
   field_B : float

Availability

  • python3.6 was released in Dec 2016(three years ago)
  • ubuntu 16.04 still defaults to python 3.5, while ubuntu 18.04 supports 3.6
  • There are ppas in 16.04 which could gain 3.6 support

Limited Support for Runtime

We can also separate the concern of supporting advanced compiler features, and support for runtime only features for 3.5.

Note that this could still complicates things for our developers. For example, I could imagine more typed objects when we lift the 3.6 limit, and some of the code could creep in. So one could also argue that we just set a simple cut.

Discussions

Please share your thoughts.

[DISCUSS] Require python3.6 vs python 3.5 compatibility
#2

Hi, Thank you for starting a discussion about this point.

Actually I’m currently using Python 3.5.2 and TVM@9bd2c7b44208ed992061 I get syntax errors while running Python RPC:

python -m tvm.exec.rpc_server --host 0.0.0.0 --port=9090
...
File "/root/tvm/python/tvm/exec/rpc_server.py", line 27, in <module>
    from tvm import micro
File "/root/tvm/python/tvm/micro/__init__.py", line 19, in <module>
    from ..contrib import binutil
File "/root/tvm/python/tvm/contrib/binutil.py", line 93
    msg = f"error while running command \"{cmd_str}\":\n{output}"
                                                            ^
SyntaxError: invalid syntax

Do we need to update the minimum required version or change the code?

Exception: TVM project proudly dropped support of Python2.
    The minimal Python requirement is Python 3.5

Thank you.

#3

This could be a missing point in this PR: https://github.com/apache/incubator-tvm/pull/4250

#4

On balance, I think it probably makes sense to move up to python 3.6 as it gives us a number of features that aren’t there in 3.5 . Further despite our coding standards we still see feature creep for python 3.6 as the CI is using python3.6 rather than python 3.5.

The main downside is that for 16.04 this is supported only with ppas though they seem to be supported for quite sometime (ppa:deadsnakes have been publishing since 2017) they are not “official” ubuntu packages.

The tension between using new popular python features and general deployability will always remain and thus once we choose a python version like python3.6 and certain features are specified we need to stick with them for :

  • either a release cycle ?
  • if we choose to use newer versions in our CI, do we have tools that would cause CI to fail when a PR lands to prevent accidental usage of newer features ?

Ramana

#5

I think it makes sense to stick with a dependency version choice for one release cycle. The CI should be kept reflecting the failure, I understand that we did not do that well when we introduce python3.5 deps, I tried to introduced python3.5 CI near the end of the 0.6 release but wanted to wait and see if 3.6 will land in the current one. In the future we should make sure that CI covers minimum support

#6

I would love a move to 3.6 mostly so we can clean up the Relay code, and bring type annotations back to the main classes and methods. This will also make it easier to increase the subset of TVM that supports MyPy type annotations, which are becoming increasingly popular and help improve the software quality tremendously imo. Every time I’ve turned it on in a TVM file I’ve found bugs due to type errors.

#7

Big fan to Python 3.6 type annotation too!

We can also consider to use mypy to check type annotation coverage. mypy will eforce required type annotations when it cannot infer the type by static analysis.

1 Like
#8

I like the type annotations support and implied MyPy usage that comes with moving up to Python 3.6 - I’ve worked in Python 3.6 codebases with type annotations and for me the type annotations and static analysis greatly benefited the development flow and my confidence in changes I made. My primary concerns would be the effect on deployability, e.g. the Ubuntu 16.04 concern, and how this plays with external integrations e.g. PyTorch.

#9

Seems we are converging to using python3.6 in 0.7, thanks everyone for the discussion. We will leave this thread open for a few days before taking further actions

#10

Thanks everyone for discussion, formal RFC here https://github.com/apache/incubator-tvm/issues/4957