Hi there,

I haven't been active in the airflow community so this should be weighed 
appropriately. 

I'm a core dev of a couple of other libraries (xarray, pandas-gbq) and have led 
initiatives to clean up the code in both of those.

While I'm very enthusiastic about auto-formatting tools, my experience is that 
finding settings that aren't overly strict but still contribute is extremely 
difficult. Have people worked on large projects with pylint? 

I thought the recent thread around improving the contribution process was 
insightful. Auto-enforcing coding standards can be v helpful for both new 
contributors and reviewers, but a bad tool makes that harder, particularly for 
new contributors who aren't used to them.

Ofc, if someone knows of large projects that successfully use pylint, I'd 
appreciate learning that my view of the tool is wrong!

Thanks for everyone's hard work,
Max

On 2019/04/11 20:50:01, Bas Harenslak <basharens...@godatadriven.com> wrote: 
> Hello Airflow community,
> 
> This email calls for a vote to introduce Pylint in the Airflow project. The 
> vote will last for at least 1 week (April 18th 23:00 CET), and at least three 
> +1 (binding) votes have been cast.
> 
> After feedback on AIP-6 and discussion on 
> Slack<https://apache-airflow.slack.com/archives/CCPRP7943/p1554962392081400>, 
> I propose to vote for adding Pylint<https://pylint.org> to the Airflow 
> project for static code checking. Pylint complements Flake8 with stricter 
> rules, detects code smells and is customisable so unnecessary checks can be 
> ignored. This should benefit the Airflow code base with consistent, 
> documented code and less errors.
> 
> Note that Pylint 2.0 works with Python 3 only, so if the vote is successful, 
> it should be introduced after dropping support for Python 2 
> (AIRFLOW-4196<https://issues.apache.org/jira/browse/AIRFLOW-4196>).
> Note2: to keep the scope as small as possible, I’ll create a separate vote 
> for Black formatting.
> 
> Cheers,
> Bas
> 

Reply via email to