Proposal create project coding standard for tryton

Proposal to create a project coding standard

use of pylint, automatic code formatting with black, start adding type hints to core libs.


  • improves code consistence and readability
  • avoids annoying editor warnings, “save time and mental energy for more important matters
  • avoids nagging about formatting
  • pylint is a tools that helps preventing certain type of bugs bugs, suggesting improvements
  • helps current developers and to board in new developers


  • applying black, pylint will create possible merge and rebase issues for existing banches
  • discussion about allowed variables names pylint and pep8 vs internal coding style example FiscalYear = pool.get('account.fiscalyear') vs fiscal_year = pool.get('account.fiscalyear')


  • discus a coding style to be shared across projects
  • publish aproved coding style at Tryton Documentation
  • create a pylintrc with the approved coding style
  • discus a time to apply black across all projects
  • add a # pylint: disable= at the beginning of each python file with the rules that are not implemented, to ease development and progressive implementation of the coding style
  • implement hooks to ensure that pylint and black are enforced at commit


  • as of python 3.5 was introduced type hints would be helpful to introduce on core libs

You can check coding guidelines on:

This points have very few to do with the coding style.
The key points are: good naming and proper design. And they are not and cannot be managed by tools.

Well that depends on everyone editors.

As I’m doing most of the reviewing, I have very little comment about format. And most of the time reviewbot has already commented.

Indeed I find that the formatting comes automatically out of a well though design. And usually bad code has bad design (even if it was linted or whatever).

We have already flake8 run by reviewbot. I do not think we must change but improve it.

I do not see how if they have to setup more tools in order to start.

Indeed it is more about backport of fixes. But it would be a major problem.

I already though about that but I could not find a way to deal with dynamic class generation Tryton has.
Maybe with a hook that create stub files automatically out of all the modules.
But anyway, this is off topic about code style.

Also for now our style was designed with back-port of patches in mind. So it tries to minimize the number of line modified (e.g. fixed indentation depending on number of opening brackets).
But an automated formatting does not do that, it may decide to use a different style because some limits are reached (I think about list with 1 item per line for example).