Type: New Feature
Affects Version/s: None
Fix Version/s: None
Python 3 has many breaking changes compared to python 2. This has an impact on our bug detection rules when some code pattern is a bug in python 3 but not in python 2.
For example, during the last sprint we we wanted to fix some False Negatives on python 3 code. In the end we postponed this fix because it would have raised False Positive bugs on python 2 code.
We also want to
better support builtin types, but many of those builtins changed between python 2 and python 3.
One might say that we shouldn't care about python 2 because its support was stopped on the first of January this year, and surveys show that 9 out of 10 python developers were using python 3.
However other sources show that there is still quite a lot of python 2 code running in some places. For example if you look at download statistics for Django, which is the biggest python web framework, you can see that 20% of total downloads are for python 2 software (current time: 18th of March 2020).
On the long run we want to focus on python 3 code, but we want to also support python 2 developers.
This ticket will:
- add a configuration parameter "sonar.python.version" where developers can write the python version they use.
- show a warning in SonarQube/SonarCloud when this parameter is not set:
Your code is analyzed as compatible with python 2 and 3 by default. This will prevent the detection of issues specific to python 2 or python 3. You can get a more precise analysis by setting a python version in your configuration via the parameter "sonar.python.version".
By default the parameter will have no value and the analyzer will suppose that the code is compatible for both python 2 and python 3. Thus any issue specific to python 2 or python 3 will not be raised.
The "pythonVersion" parameter will be a string following a subset of "Version Specifiers" as defined in PEP 440. Accepted syntax will be:
We won't accept other operators described in PEP 440 (==, !=, ~=, ===) because >=, <=, < and > are enough for our purpose. We won't accept any version more precise than a minor version ("patch", "rc", "alpha", "beta", etc...).
For now we won't make any distinction between python minor versions 2 and 3 (ex: 3.6). This however can be useful later as some apis were broken between minor versions (ex: added and removed methods/classes/modules). By enabling developers to give a more precise version right away, we will be able to raise better issues later on. We can't raise a warning later saying that the version is not precise enough.
The documentation for the parameter should be similar to the one for sonar.java.source.
Python code is analyzed by default as compatible with python 2 and python 3. Some issues will be automatically silenced to avoid raising False Positives. In order to get a more precise analysis you can specify the python versions your code supports via the sonar.python.version parameter. Its syntax is a subset of "Version Specifiers" as defined in PEP 440. Only major and minor versions are accepted as well as operators >, <, <= and >=.
The minor version is not used yet but specifying it now will improve future analysis. For example, if your code is only compatible with python 3.6+ we recommend to set the version to >= 3.6.