Mailman 3 June 2016 - code-quality

Change in unicode escape sequences
by Émanuel Barry 29 Jun '16

29 Jun '16

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

5 5

Pylint output is not constant
by Sorsa, Saija 21 Jun '16

21 Jun '16

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.

2 1

Some news regarding Pylint's release process
by Claudiu Popa 17 Jun '16

17 Jun '16

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

1 0

Average number style errors on Python
by Juan BC 13 Jun '16

13 Jun '16

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)

4 11

Flake8 User Survey
by Ian Cordasco 12 Jun '16

12 Jun '16

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

1 0

Pull request for pyflakes-study code?
by Edward K. Ream 09 Jun '16

09 Jun '16

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/ ------------------------------------------------------------------------------------------

2 1

Re: [code-quality] PyCon 2016
by Ian Cordasco 04 Jun '16

04 Jun '16

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?

2 1

PyCon 2016
by Ian Cordasco 04 Jun '16

04 Jun '16

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 ;-) )

4 3

pyflakes-study group and code
by Edward K. Ream 04 Jun '16

04 Jun '16

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/ ------------------------------------------------------------------------------------------

2 3

Patch to expose path of rcfile
by Tim Stumbaugh 03 Jun '16

03 Jun '16

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

2 3