Hello Code Quality people,
I'm writing to you today about a change that I'm proposing to CPython, which
will warn on invalid Unicode (and bytes) escape sequences, starting 3.6. It
will eventually become an error, although when is yet to be decided. See
http://bugs.python.org/issue27364 for the patch and discussion. First
message sums up pretty well what the end result will be (with maybe a few
minor differences).
As Victor Stinner and Guido both suggested, it would be good to introduce
this in the linters, to help folks who are running e.g. 3.5 (or 2.7 with
plans to migrate). So here I am, asking the maintainers of the linters to
introduce this, hopefully before 3.6.0 hits the shelves in December.
Thanks in advance!
-Emanuel
Hi,
pylint output is not constant and it reports different errors if you run it to one file in a directory compared when you run it for a multiple different files in a directory. For example:
pylint *.py
and
pylint mypython.py
gives different error messages for mypython.py-file. The error occurs when pylint processes multiple different files at the same time.
Br,
Saija
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
Hi folks,
I want with this e-mail to bring a bit of insight into what is happening
currently with Pylint, especially what are our plans regarding its releases,
and whatnot, since I'm feeling that at least this aspect is a bit opaque
to the outside world.
The current version that we are working on is 2.0, which is scheduled for
release somewhere at the beginning of July. The release date went back
and forth for a couple of times, due to not having enough time to
work on the planned features, but the approach that we will take after
the new release would simplify the process of getting out faster a new version
to the users.
There are some interesting features already implemented for the next major
release (implicit namespace package support, special object attributes
understanding, lots of bug fixes and new checks), but the major improvement
and also the reason why we are bumping the major number is represented
by the new tiered analysis. Pylint is known for being a bit
overwhelming by default, which is the reason we are planning to ease
its default interaction. The plan can be found at the corresponding issue
https://github.com/PyCQA/pylint/issues/746, but the main idea is that,
with 2.0, a pylint interaction would like this:
$ pylint myproject
# core checkers enabled
<...messages..>
10/10 - Congrats, you're clean on a core. You might try with "--pedantic" now.
$ pylint myproject --pedantic
# pedantic checkers enabled.
<...messages..>
10/10 - Congrats, you're clean on pedantic. You might try with
--refactoring now
$ pylint myproject --refactoring
# refactoring checkers enabled
<...messages..>
10/10 - Congrats, you're clean on refactoring. Last up, try with --style now.
$ pylint myproject --style
<...messages..>
10/10 - Now you're pylint clean.
or
$ pylint myproject --everything
<...messages..>
Core: 10/10
Pedantic: 10/10
Refactoring: 10/10
Style: 10/10
AGGREGATE: 10/10 -- congrats, you're pylint clean.
This feature is still in progress and you can see what is left for this
milestone here: https://github.com/PyCQA/pylint/milestones/2.0
I mentioned earlier about a new approach for handling releases
and the minor releases in particular. Since Pylint is a diverse beast,
with various areas which can be worked on at a particular time (new
features, fixing false positives, new checks, improving the inference
engine and implementing major features, such as PEP 484 support and whatnot),
the focus can be lost into one and another, leading to some areas to flourish
in the detriment of another, which can also mean that users would have to
wait even more for having a bug fix or a feature they are waiting for.
The attemptive plan is to have a short release cycle, around 2 - 3 weeks
for minor releases and around 4 - 5 months for major releases. Each minor
release would have at most 10 issues that are assigned for it, although we
might assign less than this number, just so that we could have time to
introduce more urgent bug fixes into a following release. Between some
minor releases, we will introduce gaps into the schedule for working
on the next major release. You can see the current milestones plan here
https://github.com/PyCQA/pylint/milestones, including the already
mentioned gaps. If you feel like there is an issue that is worth adding
into one milestone or another, please do not hesitate to ask.
In the end, I want to mention that we are definitely in need for more
contributors. If there is anyone who would like to do so, but does not
know how to approach the codebase or anything like this, do not
hesitate to ask, either on this mailing list or on IRC, I'm trying as
much as I can to help anyone that is interested in doing so.
All the best,
Claudiu
Hi guys i currently searching for some paper or note that has how is the
average number of style errors on python. If someone know about this kind
of work i will be pleased
--
Juan BC (from phone)
Hey all,
Flake8 3.0 is close to having a beta release (and therefore a final
release). Before that, I need some more information about the last
three things we need to implement. As such, I've made a survey to find
out what I can simplify for 3.0: http://goo.gl/forms/xiC7dt23RuGavESu1
Cheers,
Ian
Hello all,
The pyflakes-study code <https://github.com/edreamleo/pyflakes-study>
project is complete. I am wondering whether a pull request for the actual
pyflakes project would be appropriate.
I would be happy to issue the pull request, but I'm not sure how to do that
from one project (pyflakes_study) to another (pyflakes itself). Perhaps the
pyflakes devs could investigate what I have done first.
Notes:
1. Only checker.py should have to change. All other files would remain
unchanged.
2. All unit tests pass within the pyflakes-study environment, with the
exception of the api tests, which rely on the actual pyflakes directory
structure.
3. The new code uses two top-level switches, aft (use the AstFullTraverser
class) and new_scope (replace the scope property with a few other lines of
code). Leaving in these switches makes it easy to see where the
substantive changes are, but presumably they would be removed from the
final code after your evaluation.
4. I changed _FieldsOrder._get_fields during my study, but this method
disappears when aft is True. Several other important methods also
disappear when aft is True.
5. It would be possible to evaluate checker.py using any editor, but the
best view of the code is obtained by using Leo, that is,
pyflakes_study.leo. Otoh, I am not suggesting that this .leo file be part
of the official pyflakes distro.
All comments and suggestions welcome.
Edward
------------------------------------------------------------------------------------------
Edward K. Ream: edreamleo(a)gmail.com Leo: http://leoeditor.com/
------------------------------------------------------------------------------------------
On Jun 4, 2016 5:17 AM, "Ben Finney" <ben+python(a)benfinney.id.au> wrote:
>
> Florian Bruhin <me(a)the-compiler.org> writes:
>
> > Maybe https://talky.io/ would be an alternative if not everyone has a
> > Google Hangout account - I've only tried it with two people so far and
> > not a group though.
>
> To avoid vendor-locked solutions, Jitsi would be a better option
> <URL:https://meet.jit.si/>. It's free software, anyone can run an
> instance of it, or the public server can be used.
My main reason for suggesting Google hangouts on air is that people can
then watch the recording on YouTube. Do either of those allow me (or
someone else) to record the meeting so it can be uploaded?
Hi all!
As some of you may have realized, PyCon 2016 took place this week (and
sprints are still going on!). A bunch of us from this mailing list
(and also those who are no on the list) met up a couple times
throughout the week to discuss the Python Code Quality Authority,
pycodestyle, Flake8, and other similar projects.
Ian Lee, the maintainer of pycodestyle, did a lot of great work
organizing a lightning talk, open space, breakfast meetup, and sprint
on pycodestyle.
Ian and I had a few chances to speak about the future of pycodestyle
and Flake8. Those of you following along with the mailing list and
some of my probably confusing messages might realize that I'm working
on Flake8 3.0 (https://gitlab.com/pycqa/flake8/commits/proposed/3.0)
to remove most of our inner dependencies on pycodestyle (while still
using it for its expertise in check writing).
In looking over the code a little, we've decided to try to turn as
much of that work into libraries hosted in the PyCQA as possible so
pycodestyle can begin to rely on them as well.
Further, some of the responsibilities that Flake8 has taken away from
pycodestyle mean that it could, ostensibly, simplify it's internal
handling of checks if it wants to (e.g., by removing its handling of
AST checks).
In conclusion, I think that these meetings were extremely valuable. I
recognize that most of us (including me) can't afford to go to too
many of these a year, but I wonder if we should start doing virtual
meet-ups (perhaps with Google Hangouts on Air) to reap some of the
same benefits. I know PyLadies Remote has an account to do this with
and I'm sure we could create a similar account for the PyCQA/this
mailing list.
Cheers,
Ian (not Ian Lee... the other Ian ;-) )
Hello all,
I recently integrated pyflakes into Leo <http://leoeditor.com/> and am awed
by its speed and elegance. Its simplicity is pure genius. A few days ago I
set up the pyflakes-study google group
<https://groups.google.com/forum/#!forum/pyflakes-study> and
corresponding github
repo <https://github.com/edreamleo/pyflakes-study> and have been happily
playing around with the pyflakes code ever since. To properly see what I
have done you will have to look at the .leo file with Leo.
To paraphrase Richard Feynman, that which I cannot alter I do not
understand. By this criterion I now understand almost every line of
pyflakes. Hehe.
It's possible to speed up pyflakes by at least 10% by using a less elegant
traversal scheme, as describe here
<https://groups.google.com/forum/#!topic/pyflakes-study/amxtB0MKOGI>. Not
sure whether you would be interested--there are some drawbacks.
It's also possible to speed up pyflakes by an additional 5% merely by
removing the scope property, as described in today's post
<https://groups.google.com/forum/#!topic/pyflakes-study/9WoO9shG5fk>. This
post also describes a buglet in pyflakes and its fix.
Most of today's post is geared toward a new tool I am considering. This
would compare name conventions with actual usage. The first phase might be
a scope resolver, using a simplified version of the pyflakes code. The
second phase will have to do a whole lot more with Ast.Attribute :-)
You might call the new tool a follow up to my make-stub-files project
<https://groups.google.com/forum/#!topic/python-static-type-checking/n68MH1x…>,
with corresponding github repo
<https://github.com/edreamleo/make-stub-files>. I announced make-stub-files
in my largely unsuccessful python-static-typechecking
<https://groups.google.com/forum/#%21forum/python-static-type-checking>
group. Boy, am I happy mypy <http://mypy-lang.org/> is doing the heavy
lifting.
I would appreciate any comments, suggestions and corrections you might have.
Edward
------------------------------------------------------------------------------------------
Edward K. Ream: edreamleo(a)gmail.com Leo: http://leoeditor.com/
------------------------------------------------------------------------------------------
Hello,
We are in the early phases of rolling out pylint to our Python
application. We have a particularly strange setup where we use __path__
in a number of "virtual packages" in order to set the correct location
of the real package. Activating astroid's behavior which scans sys.path
(the from pkgutil import extend_path trick) in combination with
manipulating sys.path in an init-hook works great and allows pylint to
see the package the same way the interpreter does.
However, figuring out the correct path to insert onto sys.path is
unfortunately not trivial, since we support running pylint as part of
our pre-commit review tool, which runs it in a different directory but
passes --rcfile on the command-line. In order to get the correct
directory, we need to have the path of the current rcfile (be it one
that came from config.find_pylintrc or one that came from --rcfile).
Unfortunately, it seems that config.PYLINTRC does not get updated to
include the path of the file if --rcfile is given.
Our current solution to this problem is to use inspect within the
init-hook to step back up to the frame of Run and look at the
config_file member of the linter:
> init-hook=import inspect;
> sys.path.append(os.path.dirname(inspect.stack()[2][0].f_locals["linter"].config_file))
However, since this essentially couples us to the internals of pylint,
it would be nice to have something a little less invasive. I prepared a
patch to pylint/lint.py that would set config.PYLINTRC in cb_set_rcfile.
That allows the init-hook above to be replaced by:
> init-hook=sys.path.append(os.path.dirname(config.PYLINTRC))
And preserve the same behavior.
My question is, would this be a change that the project is interested
in? I didn't just want to send a pull request out of the blue, since the
actual change is trivial. Is there some better way to accomplish what I
am trying to do?
Thanks for your consideration,
tjs
--
Tim Stumbaugh
Operations
Hudson River Trading
