Hi all,
This is "mgcleveland" from #pylint. I was discussing some topics on the
IRC channel related to a tech talk I'm giving to our dev teams here at
Rackspace and a bunch of people requested copies of the slides. As a
result, I'm sending them to the list. I hope you all enjoy them!
Feedback is appreciated and welcomed. Feel free to use these slides as you
wish.
cheers,
matt
Hi everyone!
It's my pleasure to announce to you that PyLint and its Astroid library
have migrated to git from mercurial and have migrated from BitBucket to the
Python Code-Quality Authority (PyCQA) organization on GitHub.
The new URLs are:
- PyLint: https://github.com/pycqa/pylint
- Astroid: https://github.com/pycqa/astroid
For those who do not know, Pylint (http://www.pylint.org/) is a Python
source code analyzer which looks for programming errors, helps enforcing a
coding standard and sniffs for some code smells. Astroid provides a common
base representation of python source code for projects such as pychecker,
pyreverse, pylint.
Cheers,
Ian
PyCQA Administrator
Flake8, mccabe, pep8, and pyflakes core developer
Hey,
what do you think about moving pylint and astroid from Bitbucket/hg to
GitHub/git? I've briefly talked with Claudiu about this, and he seems
open to the idea and suggested I write this mail :)
If people agree, I'll be able to move issues (including the correct
issue numbers) and the repository (including tags/branches). I
recently helped doing the same for pytest:
https://bitbucket.org/pytest-dev/pytest/issues/699/
Unfortunately, I didn't find a good way to migrate pull requests, so
those would've been to be recreated by their authors.
Some rationales, from my point of view:
- GitHub has the bigger exposure, and more people are familiar with it
than with Bitbucket - this potentially means more contributors.
- Contributing is IMHO cumbersome with Bitbucket. Apparently, one's
supposed to use bookmarks instead of branches (because branches
can't be deleted, IIRC), but Bitbucket doesn't support doing pull
requests with them - the "solution" Bitbucket uses when editing
things with the online editor is to create a new fork for every
change, by the way...
I also tried to find documentation for basic stuff like "how do I
contribute to a project with branches and PRs", and found it very
difficult. Sure, I'm used to git, but getting started with git was
a lot easier than with hg/bitbucket.
- Travis CI[1] is a lot better than drone.io, the current CI system in
use. For example, one is able to test PRs, which is something
essential in a CI IMHO (and also makes contributing easier).
I don't think I need to elaborate on that :)
- There's also a lot of other potentially useful tooling which is
available for GitHub, but not BitBucket - see point 1 (bigger
exposure).
[1] https://travis-ci.org/
My plan would be to create a pylint organization on GitHub and move
the repos and issues there.
Opinions?
Florian
--
http://www.the-compiler.org | me(a)the-compiler.org (Mail/XMPP)
GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
I love long mails! | http://email.is-not-s.ms/
Hello,
I'm happy to announce you the release of Pylint 1.5.0,
respectively Astroid 1.4.1.
It's been over a year since the last major release
and the amount of changes that were brought into pylint
in this time is humongous, with over 30 new checks
and tons of bug fixes.
I would like to use this occasion for thanking for their contributions
the new committers who joined pylint's team in the past months,
ceridwen and Dmitry, as well as thanking the
contributors that made this release possible.
Here are some of the major changes of this release:
- We finally support Python 3.5 in both projects.
- We stopped depending on logilab-common, which
means that users of the popular testing framework
pytest will finally stop being confused by having
two executables with the same name doing different
things.
- Almost 30 new checks you might enjoy not having in
your project. These checks fall into multiple categories,
regarding maintainability, readability, recommendations
for improving the code, as well as new type-checking
capabilities. They are:
'wrong-import-order', 'ungrouped-imports', 'wrong-import-position',
'unneeded-not', 'simplifiable-if-condition', 'too-many-boolean-expressions'
'too-many-nested-blocks', 'multiple-imports', 'duplicate-except',
'using-constant-test', 'confusing-with-statement', 'singleton-comparison',
'misplaced-comparison-constant', 'consider-using-enumerate',
'nonlocal-and-global', 'continue-in-finally', 'misplaced-bare-raise',
'nonlocal-without-binding', 'yield-inside-async-function',
'too-many-star-expressions', 'invalid-star-assignment-target',
'import-star-module-level, 'star-needs-assignment',
'unexpected-special-method-signature', 'repeated-keyword'.
Some new type checks for finding violations of the type system
are 'unsubscriptable-object', 'unsupported-membership-test',
'not-an-iterable', 'not-context-manager', 'not-async-context-manager',
'duplicate-bases' and 'inconsistent-mro'.
- We also added a new 'extensions' component, which contains optional
checkers that needs to be activated explicitly.
These includes 'extensions.check_docs', which verifies a bunch of
properties of the docstrings, such as checking that all function,
method and constructor parameters are mentioned
in the params and types part of the docstring. Also, it checks that
there are no naming inconsistencies between the signature and
the documentation, i.e. also report documented parameters that are missing
in the signature. This is important to find cases where parameters are
renamed only in the code, not in the documentation.
Activate this checker with:
--load-plugins=pylint.extensions.check_docs
Most of the work was put into astroid though, which got more capable in this
period of time. Unfortunately, more than half of the work that went into it was
postponed for astroid 1.6 and astroid 2.0, since it wasn't deemed stable
enough for this release.
New features worth mentioning are:
- Python 3.5 support
- some of the nodes were renamed in order to be more similar to
builtin's ast module, such as Class to ClassDef, Function to
FunctionDef Getattr to Attribute etc, the old names being slated
for removal in astroid 2.0.
This affects the plugins as well, since it means that the visit
methods should use the new names instead (so visit_classdef for class).
Old names are still supported in visit methods for a while, until
pylint 2.0. Activating the warnings when running should result in
spurious PendingDeprecationWarnings when using the old node names.
- add proper grammatical names for `infered` and `ass_type` methods,
namely `inferred` and `assign_type`.
The old methods will raise PendingDeprecationWarning, being slated
for removal in astroid 2.0.
- we added a new convenience API, `astroid.parse`, which can be used
to retrieve an astroid AST from a source code string, similar to how
ast.parse can be used to obtain a Python AST from a source string.
- There's a new separate step for transforms.
Until now, the transforms were applied at the same time the tree was
being built. This was problematic if the transform functions were
using inference, since the inference was executed on a partially
constructed tree, which led to failures when post-building
information was needed.
- Better support for understanding builtins.
We're understanding a bunch of new builtins, but unfortunately
most of them weren't released, since they weren't stable
enough for now, due to some inherent problems that astroid
has. The most important that's released though is the understanding
of super, which means that we can now detect problems of sort:
class A(B, C, D):
def __init__(self):
super(A, self).call_missing_method()
You can read the complete changelog here
https://bitbucket.org/logilab/astroid/raw/4f45b6fc4c23b80b4f7154add1b9d9cee…
and https://bitbucket.org/logilab/pylint/raw/2871c4d7084478b5db02f384e4e5167641…
Now with every release there's going to be new false positives or regressions
or things that could be improved. Don't hesitate to open an issue or to
send a PR if you notice something's amiss and we'll try to have new
bug fix releases as soon as possible (you might have noticed that's
astroid 1.4.1..)
As a final note, we're planning to switch to GitHub soon, which will mean an
improved CI for us, resulting in less maintenance pain.
Thank you for reading all this and enjoy pylinting!
Claudiu
