code-quality May 2013

code-quality@python.org

11 participants
9 discussions

Variable declarations + pyflakes
by Raphael Clifford 27 May '13

27 May '13

I have recently been talking to friends/colleagues about their reasons for not using python for large projects (say from a thousand lines of code and with at least three people contributing). One of the problems that comes up time and again is the difficulty in debugging python code and in particular the simple sounding job of catching typos. One specific suggestion is the following. Make variable declaration compulsory. For example. var foo = 15 [...] var foo = 10 should return an error. Similarly

4 4

[Announcement] flake8-docstrings
by Ian Cordasco 21 May '13

21 May '13

Hey all, I'd like to announce the newest extension for Flake8 that I've poorly named flake8-docstrings. flake8-docstrings relies on the excellent pep257 for checking. Simon André did most of the work to get it completed (so don't listen to PyPI, he's the real author). `pip install flake8-docstrings` is all you need to try it out. If you find any issues or wish to contribute, we would be happy to hear from you on BitBucket: https://bitbucket.org/icordasc/flake8-docstrings. -- Ian

1 0

Re: [code-quality] [Python-projects] Pylint sprint dates: june 17-19
by Sylvain Thénault 14 May '13

14 May '13

Hi there, On 06 mai 17:40, Sylvain Thénault wrote: > talking to those who'll attend to the sprint: we have to organize the attendence > of Logilab people from Paris, and I propose to other to book room for them in the > same hotel. Just tell me if you're interested and for which nights you need an > hotel. I've rather set up a pad to prepare the sprint: http://piratepad.net/oAvsUoGCAC Those who'll attend should share information there about their travel, hotel and all. Those who intend to participate online are invited to add their name and avaibility. Anyone may suggest sprint topic and/or vote for the proposed ones. -- Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42) Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services CubicWeb, the semantic web framework: http://www.cubicweb.org

1 0

Implicit String Concatenation Threads
by Ian Cordasco 12 May '13

12 May '13

Hey all, I've been forwarding (and trying to CC) our list on those messages as much as possible. In case any of you weren't already subscribed to the python-ideas list, Guido has proposed that python no longer allow the following: foo = ('abc' 'def' ) Mainly because it can cause confusing TypeErrors for the functions taking a certain number of arguments. There are a few ideas floating around that thread, one of which is that we (the code-quality tool authors) provide warnings or errors when someone does: foo('a' 'b') i.e., uses the implicit concatenation on a single line. I'm personally far more in favor of this (mainly for older versions of python) + a SyntaxError for newer versions but to allow the multi-line concatenation to continue. Some are in favor of adding a new string prefix like `m` or `s`. All of this aside, we may have to start including support for this in our tools so I wanted everyone to be well aware of the discussion. Hopefully people will continue the trend I've tried to start of CC'ing code-quality but that likely won't happen. Cheers, Ian

2 2

Re: [code-quality] [Python-ideas] Implicit string literal concatenation considered harmful?
by Ian Cordasco 11 May '13

11 May '13

On Sat, May 11, 2013 at 12:48 PM, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > On Sun, May 12, 2013 at 2:37 AM, Christian Tismer <tismer(a)stackless.com> wrote: > >> So if there was some notation (not specified yet how) that triggers correct >> indentation at compile time without extra functional hacks, so that >> >> long_text = """ >> this text is left justified >> and this line indents by two spaces >> """ >> >> is stripped the leading and trailing \n and indentation is justified, >> then I think the need for the implicit whitespace operator would be small. > > Through participating in this thread, I've realised that the > distinction between when I use a triple quoted string (with or without > textwrap.dedent()) and when I use implicit string concatenation is > whether or not I want the newlines in the result. Often I can avoid > the issue entirely by splitting a statement into multiple pieces, but > > I think Guido's right that if we didn't have implicit string > concatenation there's no way we would add it ("just use a triple > quoted string with escaped newlines" or "just use runtime string > concatenation"), but given that we *do* have it, I don't think it's > worth the hassle of removing it over a bug that a lint program should > be able to pick up. > > So I'm back to where I started, which is that if this kind of problem > really bothers anyone, start thinking seriously about the idea of a > standard library linter. Really this should be trivial for all of the linters that already exist. That aside, (and this is not an endorsement for this proposal) but can you not just do long_text = """\ this is left justified \ and this is continued on the same line and this is indented by two spaces """ I'm personally in favor of not allowing the concatenation to be on the same line but allowing it across multiple lines. While linters would be great for this, why not just introduce the SyntaxError since (as has already been demonstrated) some of the concatenation already happens at compile time.

1 0

Fwd: [Python-ideas] Implicit string literal concatenation considered harmful?
by Ian Cordasco 11 May '13

11 May '13

---------- Forwarded message ---------- From: Nick Coghlan <ncoghlan(a)gmail.com> Date: Sat, May 11, 2013 at 12:48 PM Subject: Re: [Python-ideas] Implicit string literal concatenation considered harmful? To: Christian Tismer <tismer(a)stackless.com> Cc: Stefan Behnel <stefan_ml(a)behnel.de>, "python-ideas(a)python.org" <python-ideas(a)python.org> On Sun, May 12, 2013 at 2:37 AM, Christian Tismer <tismer(a)stackless.com> wrote: > So if there was some notation (not specified yet how) that triggers correct > indentation at compile time without extra functional hacks, so that > > long_text = """ > this text is left justified > and this line indents by two spaces > """ > > is stripped the leading and trailing \n and indentation is justified, > then I think the need for the implicit whitespace operator would be small. Through participating in this thread, I've realised that the distinction between when I use a triple quoted string (with or without textwrap.dedent()) and when I use implicit string concatenation is whether or not I want the newlines in the result. Often I can avoid the issue entirely by splitting a statement into multiple pieces, but I think Guido's right that if we didn't have implicit string concatenation there's no way we would add it ("just use a triple quoted string with escaped newlines" or "just use runtime string concatenation"), but given that we *do* have it, I don't think it's worth the hassle of removing it over a bug that a lint program should be able to pick up. So I'm back to where I started, which is that if this kind of problem really bothers anyone, start thinking seriously about the idea of a standard library linter. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org http://mail.python.org/mailman/listinfo/python-ideas

1 0

Re: [code-quality] [Python-ideas] Implicit string literal concatenation considered harmful?
by Ian Cordasco 11 May '13

11 May '13

On May 10, 2013 7:51 PM, "Nick Coghlan" <ncoghlan(a)gmail.com> wrote: > > > On 11 May 2013 04:50, "Guido van Rossum" <guido(a)python.org> wrote: > > > > I just spent a few minutes staring at a bug caused by a missing comma > > -- I got a mysterious argument count error because instead of foo('a', > > 'b') I had written foo('a' 'b'). > > > > This is a fairly common mistake, and IIRC at Google we even had a lint > > rule against this (there was also a Python dialect used for some > > specific purpose where this was explicitly forbidden). > > > > Now, with modern compiler technology, we can (and in fact do) evaluate > > compile-time string literal concatenation with the '+' operator, so > > there's really no reason to support 'a' 'b' any more. (The reason was > > always rather flimsy; I copied it from C but the reason why it's > > needed there doesn't really apply to Python, as it is mostly useful > > inside macros.) > > > > Would it be reasonable to start deprecating this and eventually remove > > it from the language? > > I could live with it if we get "dedent()" as a string method. I'd be even happier if constant folding was extended to platform independent method calls on literals, but I don't believe there's a sane way to maintain the "platform independent" constraint. > > OTOH, it's almost on the scale of "remove string mod formatting". Shipping at least a basic linting tool in the stdlib would probably be almost as effective and substantially less disruptive. lib2to3 should provide some decent infrastructure for that. I have cc'd the code-quality mailing list since several linger authors are subscribed there.

3 2

news from the Pylint front
by Sylvain Thénault 07 May '13

07 May '13

Hi there, first post to the code-quality mailing list. Among others, I've been developping and maintaining Pylint for the past 10 years with some fellows, and it seems this is now the place to be for code quality checkers, so here we go. You may be aware, or not, that things are moving these days on the pylint front. Two noticeable things: * pylint development is moving to bitbucket and away from its "parent" (Logilab) [1] * a pylint sprint will be held in Toulouse (France) from June 17 to 19, with currently 2 or 3 people from Logilab and probably at least 3 from Google [2] Following the bitbucket move, we're currently discussing about moving Pylint related discussions from its current mailing-list (python-projects(a)lists.logilab.org) to this one. You can see from the archives [3] that this is not high traffic, but neither negligeable compared to this list current traffic. Of course I would like to know opinion from people here before acting anything. Last but not least, it would be great if some flake8 fellows would be available to sprint with us, so we can see how to integrate pylint there and share efforts. Waiting for your feedbacks, cheers, [1] http://www.logilab.org/blogentry/129458 [2] http://www.logilab.org/133321 [3] http://lists.logilab.org/pipermail/python-projects/ -- Sylvain Thénault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42) Formations Python, Debian, Méth. Agiles: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services CubicWeb, the semantic web framework: http://www.cubicweb.org

3 3

pep8 checker suggestion
by harry 01 May '13

01 May '13

hi, i am currently working on an ide for python, i intended to enable pep8 checking by default but as it turned out, the checker was written purposefully for the command line making it a bit difficult and untidy to incorporate into the ide. i will therefore suggest that for future release, you enable the checker to be usable as a library so that the output can easily be processed and also the overal build of my ide will be a bit more compact. thanks.

2 2

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

code-quality May 2013