From me at the-compiler.org Tue Jun 2 09:12:39 2015 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 2 Jun 2015 09:12:39 +0200 Subject: [code-quality] New pytest plugin: pytest-mccabe Message-ID: <20150602071239.GB26357@tonks> Hi, (first of all, sorry for the cross-posting, but I can't decide on which list this belongs - at least I resisted sending it to the TIP list too :P) I recently started switching from flake8[1] to pytest-pep8[2] and pytest-flakes[3], but missed a way to run the mccabe[4] code complexity checker. So I wrote my first pytest plugin to integrate that with pytest: https://github.com/The-Compiler/pytest-mccabe Any feedback is welcome! I plan to write some more tests (for the config wildcards mainly) and run pylint/pyflakes/pep8 over it, and then I'll release v0.1 on PyPI. Thanks to: - Florian Schulze for pytest-flakes, on which the code is based. - Ned Batchelder for the original McCabe script. - Florent Xicluna for mccabe on PyPI. Florian [1] https://pypi.python.org/pypi/flake8 [2] https://pypi.python.org/pypi/pytest-pep8 [3] https://pypi.python.org/pypi/pytest-flakes [4] https://pypi.python.org/pypi/mccabe -- http://www.the-compiler.org | me at 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From me at the-compiler.org Tue Jun 2 10:48:27 2015 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 2 Jun 2015 10:48:27 +0200 Subject: [code-quality] [pytest-dev] New pytest plugin: pytest-mccabe In-Reply-To: References: <20150602071239.GB26357@tonks> Message-ID: <20150602084827.GC26357@tonks> * Anatoly Bubenkov [2015-06-02 08:41:12 +0000]: > there's a pylama project which is a bit buggy at error reporting, but it > solves the code checks as a whole, which i appreciate > > https://github.com/klen/pylama > > So it general solution for code checks but it's also a pytest plugin which > includes mccabe checks > > I use it in several projects I've seen that, but at least if I can believe the documentation it can't run pylint for python 3: Pylint isn't supported in Python 3. Also I really dislike its approach of bundling the checkers instead of depending on them ;) So far, pytest-{pep8,flakes,mccabe} do all I want :) Florian -- http://www.the-compiler.org | me at 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/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From bubenkoff at gmail.com Tue Jun 2 10:41:12 2015 From: bubenkoff at gmail.com (Anatoly Bubenkov) Date: Tue, 02 Jun 2015 08:41:12 +0000 Subject: [code-quality] [pytest-dev] New pytest plugin: pytest-mccabe In-Reply-To: <20150602071239.GB26357@tonks> References: <20150602071239.GB26357@tonks> Message-ID: there's a pylama project which is a bit buggy at error reporting, but it solves the code checks as a whole, which i appreciate https://github.com/klen/pylama So it general solution for code checks but it's also a pytest plugin which includes mccabe checks I use it in several projects On Tue, Jun 2, 2015 at 9:12 AM Florian Bruhin wrote: > Hi, > > (first of all, sorry for the cross-posting, but I can't decide on which > list this belongs - at least I resisted sending it to the TIP list > too :P) > > I recently started switching from flake8[1] to pytest-pep8[2] and > pytest-flakes[3], but missed a way to run the mccabe[4] code > complexity checker. > > So I wrote my first pytest plugin to integrate that with pytest: > > https://github.com/The-Compiler/pytest-mccabe > > Any feedback is welcome! I plan to write some more tests (for the > config wildcards mainly) and run pylint/pyflakes/pep8 over it, and > then I'll release v0.1 on PyPI. > > Thanks to: > > - Florian Schulze for pytest-flakes, on which the code is based. > - Ned Batchelder for the original McCabe script. > - Florent Xicluna for mccabe on PyPI. > > Florian > > [1] https://pypi.python.org/pypi/flake8 > [2] https://pypi.python.org/pypi/pytest-pep8 > [3] https://pypi.python.org/pypi/pytest-flakes > [4] https://pypi.python.org/pypi/mccabe > > -- > http://www.the-compiler.org | me at 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/ > _______________________________________________ > pytest-dev mailing list > pytest-dev at python.org > https://mail.python.org/mailman/listinfo/pytest-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bubenkoff at gmail.com Tue Jun 2 10:49:26 2015 From: bubenkoff at gmail.com (Anatoly Bubenkov) Date: Tue, 02 Jun 2015 08:49:26 +0000 Subject: [code-quality] [pytest-dev] New pytest plugin: pytest-mccabe In-Reply-To: <20150602084827.GC26357@tonks> References: <20150602071239.GB26357@tonks> <20150602084827.GC26357@tonks> Message-ID: docs lie, it works for python3 :) On Tue, Jun 2, 2015 at 10:48 AM Florian Bruhin wrote: > * Anatoly Bubenkov [2015-06-02 08:41:12 +0000]: > > there's a pylama project which is a bit buggy at error reporting, but it > > solves the code checks as a whole, which i appreciate > > > > https://github.com/klen/pylama > > > > So it general solution for code checks but it's also a pytest plugin > which > > includes mccabe checks > > > > I use it in several projects > > I've seen that, but at least if I can believe the documentation it > can't run pylint for python 3: > > Pylint isn't supported in Python 3. > > Also I really dislike its approach of bundling the checkers instead of > depending on them ;) > > So far, pytest-{pep8,flakes,mccabe} do all I want :) > > Florian > > -- > http://www.the-compiler.org | me at 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/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From techtonik at gmail.com Wed Jun 3 12:59:44 2015 From: techtonik at gmail.com (anatoly techtonik) Date: Wed, 3 Jun 2015 13:59:44 +0300 Subject: [code-quality] Test for checking linefeeds Message-ID: Hi, I don't want to reinvent to bicycle (even though it is easy), so is there a support for checking linefeeds in any of the existing linter tools? The two checks in particular are interesting: 1. test that files don't have mixed linefeeeds 2. test that files comply with project linefeed style (LF in particular) This is needed for Travis checks, but I also want to run it standalone on Windows, so grep won't work. https://github.com/spyder-ide/spyder/issues/2424 Thanks. -- anatoly t. From pcmanticore at gmail.com Thu Jun 4 15:08:34 2015 From: pcmanticore at gmail.com (Claudiu Popa) Date: Thu, 4 Jun 2015 16:08:34 +0300 Subject: [code-quality] Test for checking linefeeds In-Reply-To: References: Message-ID: On Wed, Jun 3, 2015 at 1:59 PM, anatoly techtonik wrote: > Hi, > > I don't want to reinvent to bicycle (even though it is easy), > so is there a support for checking linefeeds in any of the > existing linter tools? > > The two checks in particular are interesting: > 1. test that files don't have mixed linefeeeds > 2. test that files comply with project linefeed style (LF > in particular) > > This is needed for Travis checks, but I also want to run > it standalone on Windows, so grep won't work. > https://github.com/spyder-ide/spyder/issues/2424 > > Thanks. > -- > anatoly t. > _______________________________________________ > code-quality mailing list > code-quality at python.org > https://mail.python.org/mailman/listinfo/code-quality Try pylint: $ pylint a.py -rn --expected-line-ending-format=LF C: 1, 0: Unexpected line ending format. There is 'LF' while it should be 'CRLF'. (unexpected-line-ending-format C: 3, 0: Mixed line endings LF and CRLF (mixed-line-endings) From pcmanticore at gmail.com Thu Jun 4 15:09:39 2015 From: pcmanticore at gmail.com (Claudiu Popa) Date: Thu, 4 Jun 2015 16:09:39 +0300 Subject: [code-quality] Test for checking linefeeds In-Reply-To: References:

Message-ID: On Thu, Jun 4, 2015 at 4:08 PM, Claudiu Popa wrote: > On Wed, Jun 3, 2015 at 1:59 PM, anatoly techtonik wrote: >> Hi, >> >> I don't want to reinvent to bicycle (even though it is easy), >> so is there a support for checking linefeeds in any of the >> existing linter tools? >> >> The two checks in particular are interesting: >> 1. test that files don't have mixed linefeeeds >> 2. test that files comply with project linefeed style (LF >> in particular) >> >> This is needed for Travis checks, but I also want to run >> it standalone on Windows, so grep won't work. >> https://github.com/spyder-ide/spyder/issues/2424 >> >> Thanks. >> -- >> anatoly t. >> _______________________________________________ >> code-quality mailing list >> code-quality at python.org >> https://mail.python.org/mailman/listinfo/code-quality > > > Try pylint: > > $ pylint a.py -rn --expected-line-ending-format=LF > C: 1, 0: Unexpected line ending format. There is 'LF' while it should > be 'CRLF'. (unexpected-line-ending-format > C: 3, 0: Mixed line endings LF and CRLF (mixed-line-endings) The actual command was pylint a.py -rn --expected-line-ending-format=CRLF. From pcmanticore at gmail.com Thu Jun 4 20:42:45 2015 From: pcmanticore at gmail.com (Claudiu Popa) Date: Thu, 4 Jun 2015 21:42:45 +0300 Subject: [code-quality] Test for checking linefeeds In-Reply-To: References:

Message-ID: On Thu, Jun 4, 2015 at 9:30 PM, anatoly techtonik wrote: > Found the command: > py -2 -m pylint --reports=n --disable=all > --enable=trailing-whitespace,mixed-line-endings,unexpected-line-ending-format > --expected-line-ending-format=LF file.py > > Now how to run that on all modules/packages recursively? > You can use `py -2 pylint package`, it will run on all package's modules. We don't support (yet) something like `py -2 pylint *.py` though. From pcmanticore at gmail.com Thu Jun 4 20:58:36 2015 From: pcmanticore at gmail.com (Claudiu Popa) Date: Thu, 4 Jun 2015 21:58:36 +0300 Subject: [code-quality] Test for checking linefeeds In-Reply-To: References:

Message-ID: On Thu, Jun 4, 2015 at 9:47 PM, anatoly techtonik wrote: > > Does it support multiple modules like `pylint package1 package1 ...`? > Command line help looks like it doesn't. > > Also, is it possible to limit CRLF mismatch message to a single line per > file if all lines are in the wrong format? > https://travis-ci.org/spyder-ide/spyder/jobs/65453904 > > -- > anatoly t. Yes, you can give to it multiple packages. If it's not clear from the documentation, maybe it's a bug. Regarding your last question, no..pylint is quite pedantic and it emits the same message for every line that has the given problem. From techtonik at gmail.com Thu Jun 4 20:30:50 2015 From: techtonik at gmail.com (anatoly techtonik) Date: Thu, 4 Jun 2015 21:30:50 +0300 Subject: [code-quality] Test for checking linefeeds In-Reply-To: References:

Message-ID: Found the command: py -2 -m pylint --reports=n --disable=all --enable=trailing-whitespace,mixed-line-endings,unexpected-line-ending-format --expected-line-ending-format=LF file.py Now how to run that on all modules/packages recursively? On Thu, Jun 4, 2015 at 9:20 PM, anatoly techtonik wrote: > That helps, thanks. How to run only this check on app *.py files in repository? > I found codenames C0327 (mixed line endings) and C0328 (unexpected feeds) > > On Thu, Jun 4, 2015 at 4:09 PM, Claudiu Popa wrote: >> On Thu, Jun 4, 2015 at 4:08 PM, Claudiu Popa wrote: >>> On Wed, Jun 3, 2015 at 1:59 PM, anatoly techtonik wrote: >>>> Hi, >>>> >>>> I don't want to reinvent to bicycle (even though it is easy), >>>> so is there a support for checking linefeeds in any of the >>>> existing linter tools? >>>> >>>> The two checks in particular are interesting: >>>> 1. test that files don't have mixed linefeeeds >>>> 2. test that files comply with project linefeed style (LF >>>> in particular) >>>> >>>> This is needed for Travis checks, but I also want to run >>>> it standalone on Windows, so grep won't work. >>>> https://github.com/spyder-ide/spyder/issues/2424 >>>> >>>> Thanks. >>>> -- >>>> anatoly t. >>>> _______________________________________________ >>>> code-quality mailing list >>>> code-quality at python.org >>>> https://mail.python.org/mailman/listinfo/code-quality >>> >>> >>> Try pylint: >>> >>> $ pylint a.py -rn --expected-line-ending-format=LF >>> C: 1, 0: Unexpected line ending format. There is 'LF' while it should >>> be 'CRLF'. (unexpected-line-ending-format >>> C: 3, 0: Mixed line endings LF and CRLF (mixed-line-endings) >> >> >> The actual command was pylint a.py -rn --expected-line-ending-format=CRLF. > > > > -- > anatoly t. -- anatoly t. From techtonik at gmail.com Thu Jun 4 20:47:02 2015 From: techtonik at gmail.com (anatoly techtonik) Date: Thu, 4 Jun 2015 21:47:02 +0300 Subject: [code-quality] Test for checking linefeeds In-Reply-To: References:

Message-ID: On Thu, Jun 4, 2015 at 9:42 PM, Claudiu Popa wrote: > On Thu, Jun 4, 2015 at 9:30 PM, anatoly techtonik wrote: >> Found the command: >> py -2 -m pylint --reports=n --disable=all >> --enable=trailing-whitespace,mixed-line-endings,unexpected-line-ending-format >> --expected-line-ending-format=LF file.py >> >> Now how to run that on all modules/packages recursively? >> > > You can use `py -2 pylint package`, it will run on all package's modules. > > We don't support (yet) something like `py -2 pylint *.py` though. Does it support multiple modules like `pylint package1 package1 ...`? Command line help looks like it doesn't. Also, is it possible to limit CRLF mismatch message to a single line per file if all lines are in the wrong format? https://travis-ci.org/spyder-ide/spyder/jobs/65453904 -- anatoly t. From techtonik at gmail.com Thu Jun 4 20:20:06 2015 From: techtonik at gmail.com (anatoly techtonik) Date: Thu, 4 Jun 2015 21:20:06 +0300 Subject: [code-quality] Test for checking linefeeds In-Reply-To: References:

Message-ID: That helps, thanks. How to run only this check on app *.py files in repository? I found codenames C0327 (mixed line endings) and C0328 (unexpected feeds) On Thu, Jun 4, 2015 at 4:09 PM, Claudiu Popa wrote: > On Thu, Jun 4, 2015 at 4:08 PM, Claudiu Popa wrote: >> On Wed, Jun 3, 2015 at 1:59 PM, anatoly techtonik wrote: >>> Hi, >>> >>> I don't want to reinvent to bicycle (even though it is easy), >>> so is there a support for checking linefeeds in any of the >>> existing linter tools? >>> >>> The two checks in particular are interesting: >>> 1. test that files don't have mixed linefeeeds >>> 2. test that files comply with project linefeed style (LF >>> in particular) >>> >>> This is needed for Travis checks, but I also want to run >>> it standalone on Windows, so grep won't work. >>> https://github.com/spyder-ide/spyder/issues/2424 >>> >>> Thanks. >>> -- >>> anatoly t. >>> _______________________________________________ >>> code-quality mailing list >>> code-quality at python.org >>> https://mail.python.org/mailman/listinfo/code-quality >> >> >> Try pylint: >> >> $ pylint a.py -rn --expected-line-ending-format=LF >> C: 1, 0: Unexpected line ending format. There is 'LF' while it should >> be 'CRLF'. (unexpected-line-ending-format >> C: 3, 0: Mixed line endings LF and CRLF (mixed-line-endings) > > > The actual command was pylint a.py -rn --expected-line-ending-format=CRLF. -- anatoly t. From techtonik at gmail.com Thu Jun 4 21:21:58 2015 From: techtonik at gmail.com (anatoly techtonik) Date: Thu, 4 Jun 2015 22:21:58 +0300 Subject: [code-quality] Test for checking linefeeds In-Reply-To: References:

Message-ID: On Thu, Jun 4, 2015 at 9:58 PM, Claudiu Popa wrote: > On Thu, Jun 4, 2015 at 9:47 PM, anatoly techtonik wrote: >> >> Does it support multiple modules like `pylint package1 package1 ...`? >> Command line help looks like it doesn't. >> >> Also, is it possible to limit CRLF mismatch message to a single line per >> file if all lines are in the wrong format? >> https://travis-ci.org/spyder-ide/spyder/jobs/65453904 > > Yes, you can give to it multiple packages. If it's not clear from > the documentation, maybe it's a bug. Not from documentation, but from command line help. At least with pylint 1.4.0 > Regarding your last question, > no..pylint is quite pedantic and it emits the same message for every line > that has the given problem. On the other hand, that's not a big deal. Thanks. -- anatoly t. From techtonik at gmail.com Sun Jun 7 23:22:23 2015 From: techtonik at gmail.com (anatoly techtonik) Date: Mon, 8 Jun 2015 00:22:23 +0300 Subject: [code-quality] pylint crashes with RuntimeError: maximum recursion depth exceeded Message-ID: Hi, pylint crashes with whitespace and linefeeds checks. https://travis-ci.org/spyder-ide/spyder/jobs/65808371 I am not sure where it failed, and why it didn't return with error status -1. Is it possible to fix return code and show the name of file that caused the recursion? -- anatoly t. From pcmanticore at gmail.com Mon Jun 8 00:10:13 2015 From: pcmanticore at gmail.com (Claudiu Popa) Date: Mon, 8 Jun 2015 01:10:13 +0300 Subject: [code-quality] pylint crashes with RuntimeError: maximum recursion depth exceeded In-Reply-To: References: Message-ID: On Mon, Jun 8, 2015 at 12:22 AM, anatoly techtonik wrote: > Hi, > > pylint crashes with whitespace and linefeeds checks. > > https://travis-ci.org/spyder-ide/spyder/jobs/65808371 > > I am not sure where it failed, and why it didn't return > with error status -1. Is it possible to fix return code > and show the name of file that caused the recursion? > > -- > anatoly t. Hi, Could you provide the pylint version and the astroid version? From contact at jeffquast.com Mon Jun 8 01:20:57 2015 From: contact at jeffquast.com (Jeff Quast) Date: Sun, 7 Jun 2015 16:20:57 -0700 Subject: [code-quality] pylint crashes with RuntimeError: maximum recursion depth exceeded In-Reply-To: References:

Message-ID: <64C8CD8D-16C3-4977-AE8A-BB8F47C336D0@jeffquast.com> > On Jun 7, 2015, at 3:10 PM, Claudiu Popa wrote: > On Mon, Jun 8, 2015 at 12:22 AM, anatoly techtonik wrote: >> Hi, >> >> pylint crashes with whitespace and linefeeds checks. >> >> https://travis-ci.org/spyder-ide/spyder/jobs/65808371 >> >> I am not sure where it failed, and why it didn't return >> with error status -1. Is it possible to fix return code >> and show the name of file that caused the recursion? >> >> -- >> anatoly t. > > > Hi, > > Could you provide the pylint version and the astroid version? Outsider, here. From build log: astroid 1.3.4-py27_0 pylint-1.4.2-py27_0 As displayed by output of command ?conda install?, https://github.com/spyder-ide/spyder/blob/76a9a5fd721b74b37bb3eac18855b2b55b16b100/continuous_integration/travis_install.sh#L59 From techtonik at gmail.com Mon Jun 8 09:14:42 2015 From: techtonik at gmail.com (anatoly techtonik) Date: Mon, 8 Jun 2015 10:14:42 +0300 Subject: [code-quality] pylint crashes with RuntimeError: maximum recursion depth exceeded In-Reply-To: <64C8CD8D-16C3-4977-AE8A-BB8F47C336D0@jeffquast.com> References:

<64C8CD8D-16C3-4977-AE8A-BB8F47C336D0@jeffquast.com> Message-ID: On Mon, Jun 8, 2015 at 2:20 AM, Jeff Quast wrote: >> On Jun 7, 2015, at 3:10 PM, Claudiu Popa wrote: >> On Mon, Jun 8, 2015 at 12:22 AM, anatoly techtonik wrote: >>> Hi, >>> >>> pylint crashes with whitespace and linefeeds checks. >>> >>> https://travis-ci.org/spyder-ide/spyder/jobs/65808371 >>> >>> I am not sure where it failed, and why it didn't return >>> with error status -1. Is it possible to fix return code >>> and show the name of file that caused the recursion? >>> >>> -- >>> anatoly t. >> >> >> Hi, >> >> Could you provide the pylint version and the astroid version? > > Outsider, here. From build log: > > astroid 1.3.4-py27_0 > pylint-1.4.2-py27_0 > > As displayed by output of command ?conda install?, > > https://github.com/spyder-ide/spyder/blob/76a9a5fd721b74b37bb3eac18855b2b55b16b100/continuous_integration/travis_install.sh#L59 Yes, it is around the line 484 in the build log: https://travis-ci.org/spyder-ide/spyder/jobs/65808372#L484 I could also repeat it locally with pylint 1.4.0 and astroid 1.3.2, but after upgrade to pylint 1.4.3 astroid 1.3.6 the error is gone. Still no glue what happened, and no idea how to update those conda packages. -- anatoly t. From skip.montanaro at gmail.com Wed Jun 10 21:26:14 2015 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Wed, 10 Jun 2015 14:26:14 -0500 Subject: [code-quality] Spurious unused variable messages Message-ID: Code like this: import os import tempfile def func(): (fd, tmpfile) = tempfile.mkstemp(dir="/tmp") os.close(fd) print "{tmpfile}".format(**locals()) generates an unused variable warning for tmpfile, even though it's referenced in the string in the print statement. The string module has a Formatter class (since 2.6, apparently) which knows how to tear such format strings apart: >>> for elt in fmt.parse("{} {tmpfile} {1} {0:.3f}"): ... print elt ... ('', '', '', None) (' ', 'tmpfile', '', None) (' ', '1', '', None) (' ', '0', '.3f', None) I'm only now getting comfortable with the new string formatting stuff, but it seems to me that the most common use case will be to call the format method of a string literal (so this sort of usage should be fairly easy to detect). I don't think it should be terribly difficult to intersect the names coming out of Formatter.parse with the otherwise unused local variables, but I am completely unfamiliar with pylint's node traversal handlers (all the visit_* methods in variables.py). Can someone point me to some documentation for how this works, and what visit_* methods I can define? Thanks, Skip Montanaro From graffatcolmingov at gmail.com Wed Jun 10 22:48:55 2015 From: graffatcolmingov at gmail.com (Ian Cordasco) Date: Wed, 10 Jun 2015 15:48:55 -0500 Subject: [code-quality] Spurious unused variable messages In-Reply-To: References: Message-ID: On Wed, Jun 10, 2015 at 2:26 PM, Skip Montanaro wrote: > Code like this: > > import os > import tempfile > > def func(): > (fd, tmpfile) = tempfile.mkstemp(dir="/tmp") > os.close(fd) > print "{tmpfile}".format(**locals()) > > generates an unused variable warning for tmpfile, even though it's > referenced in the string in the print statement. The string module has > a Formatter class (since 2.6, apparently) which knows how to tear such > format strings apart: > > >>> for elt in fmt.parse("{} {tmpfile} {1} {0:.3f}"): > ... print elt > ... > ('', '', '', None) > (' ', 'tmpfile', '', None) > (' ', '1', '', None) > (' ', '0', '.3f', None) > > I'm only now getting comfortable with the new string formatting stuff, > but it seems to me that the most common use case will be to call the > format method of a string literal (so this sort of usage should be > fairly easy to detect). I don't think it should be terribly difficult > to intersect the names coming out of Formatter.parse with the > otherwise unused local variables, but I am completely unfamiliar with > pylint's node traversal handlers (all the visit_* methods in > variables.py). Can someone point me to some documentation for how > this works, and what visit_* methods I can define? > > Thanks, > > Skip Montanaro So, I'm not sure how much pylint will read into that statement. It has to recognize a few things: 1. String formatting (admittedly not that hard when the string wasn't built up, as in this example) 2. Passing and splatting locals in a call to format 3. Use of keyword arguments in the format Keep in mind, I'm not saying this shouldn't be fixed (or that it can't) just that there's a lot in play in this example beyond simply parsing the new string format. Apropos of nothing, the empty {} only works on 2.7 and beyond. 2.6 didn't support that. If you're going for 2.6 compat, you'll want to avoid that. From skip.montanaro at gmail.com Wed Jun 10 23:02:01 2015 From: skip.montanaro at gmail.com (Skip Montanaro) Date: Wed, 10 Jun 2015 16:02:01 -0500 Subject: [code-quality] Spurious unused variable messages In-Reply-To: References:

Message-ID: On Wed, Jun 10, 2015 at 3:48 PM, Ian Cordasco wrote: > So, I'm not sure how much pylint will read into that statement. It > has to recognize a few things: > > 1. String formatting (admittedly not that hard when the string wasn't > built up, as in this example) As I stated, I think that string literal formatting will be the most common form. The token stream around that should look something like STRING-LITERAL DOT "format" (however that's spelled). What I'm initially interested in knowing is what visit_* method(s) would be involved in processing such a construct. I really don't have any idea where to begin. I think it's going to involve astroid, but I haven't found any documentation so far. In particular, I'm really only interested in the case where a variable is otherwise unused within the function, as tmpfile was in my example. I've encountered this same issue before with printf-style dict-based formatting, but I started thinking about it again when I discovered that Python's standard string module has a Formatter class which can already parse formatting strings. > 2. Passing and splatting locals in a call to format Not a big deal. In fact, I think you can completely ignore the argument to format(), certainly to start with and for this particular task. > 3. Use of keyword arguments in the format Not sure what you're getting at here. > Keep in mind, I'm not saying this shouldn't be fixed (or that it > can't) just that there's a lot in play in this example beyond simply > parsing the new string format. Is it possible to build an add-on for pylint which I could mess around with? If so, and if I can learn how the basic token traversal works, then I think I could mess around without tickling core pylint. > Apropos of nothing, the empty {} only works on 2.7 and beyond. 2.6 > didn't support that. If you're going for 2.6 compat, you'll want to > avoid that. Not an issue. I only mentioned 2.6 because that's when the string.Formatter class appeared. In my own environment, 2.7 is the standard. From pcmanticore at gmail.com Wed Jun 10 23:28:45 2015 From: pcmanticore at gmail.com (Claudiu Popa) Date: Thu, 11 Jun 2015 00:28:45 +0300 Subject: [code-quality] Spurious unused variable messages In-Reply-To: References:

Message-ID: Hi, On Thu, Jun 11, 2015 at 12:02 AM, Skip Montanaro wrote: > > As I stated, I think that string literal formatting will be the most > common form. The token stream around that should look something like > > STRING-LITERAL DOT "format" > > (however that's spelled). What I'm initially interested in knowing is > what visit_* method(s) would be involved in processing such a > construct. I really don't have any idea where to begin. I think it's > going to involve astroid, but I haven't found any documentation so > far. Unfortunately, we don't have a very good documentation, so most of the time, you can find more about something by reading the code or asking on IRC, rather than trying to find it in the documentation. That being said, regarding your use case, I don't think you actually need to implement any visit traversal function. Here's a suggestion: In checkers.variables.leave_function, when determined that there are unused variables, call a function which gathers all the string formatting calls from the function's scope, by doing something like this: for callfunc in node.nodes_of_class(astroid.CallFunc): # Infer it func = utils.safe_infer(callfunc.func) # Check if it is a string if (isinstance(func, astroid.BoundMethod) and isinstance(func.bound, astroid.Instance) and func.bound.name in ('str', 'unicode', 'bytes')): if func.name == 'format': # start parsing the string and gather the used variables. Having the list of used variables from the parsed strings, pop them out of the container of unused variables (not_consumed) and that should be it. Of course, you should check that the string formatting uses **locals. > > Is it possible to build an add-on for pylint which I could mess around > with? If so, and if I can learn how the basic token traversal works, > then I think I could mess around without tickling core pylint. Well, you could start playing with astroid first. Start by building an AST module using astroid.AstroidBuilder: from astroid.builder import AstroidBuilder ast = AstroidBuilder().string_build(code_string) The traversal just calls visit_ and leave_ (see pylint.utils.PyLintASTWalker). > >> Apropos of nothing, the empty {} only works on 2.7 and beyond. 2.6 >> didn't support that. If you're going for 2.6 compat, you'll want to >> avoid that. > > Not an issue. I only mentioned 2.6 because that's when the > string.Formatter class appeared. In my own environment, 2.7 is the > standard. Pylint 1.4+ doesn't support Python 2.6 anymore. Hope this info helps. /Claudiu From joesmoe10 at gmail.com Sat Jun 27 07:18:12 2015 From: joesmoe10 at gmail.com (Joe Schafer) Date: Sat, 27 Jun 2015 01:18:12 -0400 Subject: [code-quality] Pylint Werkzeug plugin Message-ID: Hi all, I'm trying to extend pylint to recognize Werkzeug's import trickery. Werkzeug uses a variable called `all_by_module` in https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/__init__.py to lazily load modules. Pylint doesn't recognize this scheme and flags statements like: from werkzeug import secure_filename My attempt to fix the problem is at https://github.com/jschaf/pylint-werkzeug/blob/master/pylint_werkzeug/__init__.py I don't think I'm following an optimal path to success. Basically, I'm trying to recreate Python's import logic and then generate an AST with astroid. It's not going well. The current solution recurses endlessly, since creating the AST seems to trigger the pylint transform plugin. I'm looking for simpler or more robust alternatives to my current approach with imports. My problem seems somewhat related to the issue about changing flask.ext imports at https://bitbucket.org/logilab/astroid/issue/10/ Do you have any suggestions? Thanks, Joe Schafer -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcmanticore at gmail.com Sat Jun 27 16:57:26 2015 From: pcmanticore at gmail.com (Claudiu Popa) Date: Sat, 27 Jun 2015 17:57:26 +0300 Subject: [code-quality] Pylint Werkzeug plugin In-Reply-To: References: Message-ID: On Sat, Jun 27, 2015 at 8:18 AM, Joe Schafer wrote: > Hi all, > > I'm trying to extend pylint to recognize Werkzeug's import trickery. > > Werkzeug uses a variable called `all_by_module` in > https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/__init__.py to > lazily load modules. Pylint doesn't recognize this scheme and flags > statements like: > > from werkzeug import secure_filename > > My attempt to fix the problem is at > https://github.com/jschaf/pylint-werkzeug/blob/master/pylint_werkzeug/__init__.py > > I don't think I'm following an optimal path to success. Basically, I'm > trying to recreate Python's import logic and then generate an AST with > astroid. It's not going well. The current solution recurses endlessly, > since creating the AST seems to trigger the pylint transform plugin. I'm > looking for simpler or more robust alternatives to my current approach with > imports. > > My problem seems somewhat related to the issue about changing flask.ext > imports at https://bitbucket.org/logilab/astroid/issue/10/ > > Do you have any suggestions? > > Thanks, > Joe Schafer > Hi Joe, You could try something similar to the six.moves transform: https://bitbucket.org/logilab/astroid/src/0fa5de5411866d2d17ef0c6f43665f6463e83fa5/astroid/brain/pysix_moves.py?at=default#cl-239 Basically something along these lines: def werkzeug_transform(): code = textwrap.dedent(''' from werkzeug.useragents import UserAgent from werkzeug.http import parse_etags .... ''') return AstroidBuilder().string_build(code) astroid.register_module_extender(MANAGER, 'werkzeug', werkzeug_transform) From joesmoe10 at gmail.com Sun Jun 28 01:32:48 2015 From: joesmoe10 at gmail.com (Joe Schafer) Date: Sat, 27 Jun 2015 23:32:48 +0000 Subject: [code-quality] Pylint Werkzeug plugin In-Reply-To: References: Message-ID: Thanks Claudiu, worked like a charm. On Sat, Jun 27, 2015, 10:57 AM Claudiu Popa wrote: > On Sat, Jun 27, 2015 at 8:18 AM, Joe Schafer wrote: > > Hi all, > > > > I'm trying to extend pylint to recognize Werkzeug's import trickery. > > > > Werkzeug uses a variable called `all_by_module` in > > https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/__init__.py > to > > lazily load modules. Pylint doesn't recognize this scheme and flags > > statements like: > > > > from werkzeug import secure_filename > > > > My attempt to fix the problem is at > > > https://github.com/jschaf/pylint-werkzeug/blob/master/pylint_werkzeug/__init__.py > > > > I don't think I'm following an optimal path to success. Basically, I'm > > trying to recreate Python's import logic and then generate an AST with > > astroid. It's not going well. The current solution recurses endlessly, > > since creating the AST seems to trigger the pylint transform plugin. I'm > > looking for simpler or more robust alternatives to my current approach > with > > imports. > > > > My problem seems somewhat related to the issue about changing flask.ext > > imports at https://bitbucket.org/logilab/astroid/issue/10/ > > > > Do you have any suggestions? > > > > Thanks, > > Joe Schafer > > > > > Hi Joe, > > You could try something similar to the six.moves transform: > > https://bitbucket.org/logilab/astroid/src/0fa5de5411866d2d17ef0c6f43665f6463e83fa5/astroid/brain/pysix_moves.py?at=default#cl-239 > > Basically something along these lines: > > def werkzeug_transform(): > code = textwrap.dedent(''' > from werkzeug.useragents import UserAgent > from werkzeug.http import parse_etags > .... > ''') > return AstroidBuilder().string_build(code) > > astroid.register_module_extender(MANAGER, 'werkzeug', > werkzeug_transform) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahirnish at arista.com Mon Jun 29 11:32:56 2015 From: ahirnish at arista.com (Ahirnish Pareek) Date: Mon, 29 Jun 2015 15:02:56 +0530 Subject: [code-quality] Adding python function arguments related customized rule in pylint Message-ID: Hi all, I want to add a customized check to my pylintrc file to check and report cases whenever I define a function in a python file like this: def foo( var1, name1=value, *args ): The problem that I want to deal with is that we should not have keyword arguments( *name1* ) before positional arguments( **args* ). Although the function can still be called by passing *name1* as positional argument but there would be no way to not specify *name1* but specify **args*. How can I add this check to pylintrc file? Thanks in advance! -- Regards, Ahirnish -------------- next part -------------- An HTML attachment was scrubbed... URL: From pcmanticore at gmail.com Mon Jun 29 20:16:07 2015 From: pcmanticore at gmail.com (Claudiu Popa) Date: Mon, 29 Jun 2015 21:16:07 +0300 Subject: [code-quality] Adding python function arguments related customized rule in pylint In-Reply-To: References: Message-ID: On Mon, Jun 29, 2015 at 12:32 PM, Ahirnish Pareek wrote: > Hi all, > > I want to add a customized check to my pylintrc file to check and report > cases whenever I define a function in a python file like this: > > def foo( var1, name1=value, *args ): > > The problem that I want to deal with is that we should not have keyword > arguments( name1 ) before positional arguments( *args ). Although the > function can still be called by passing name1 as positional argument but > there would be no way to not specify name1 but specify *args. > > How can I add this check to pylintrc file? > > Thanks in advance! > > Hi, If you already have the checker, you can add it in the load-plugins entry from the pylintrc file, as in `load-plugins=qualified plugin path`. We don't have this check builtin right now, but it's something that could be useful, so if you could send it upstream, that would be really awesome. Thanks, Claudiu From Peter.Danecek at ingv.it Mon Jun 29 20:24:54 2015 From: Peter.Danecek at ingv.it (Peter Danecek) Date: Mon, 29 Jun 2015 20:24:54 +0200 Subject: [code-quality] pep8 vs. flake8 incompatibility ... Message-ID: <41A0C768-150D-4F36-BCD7-4FD299DDD637@ingv.it> Dear all, I am writing this mail, after I was directed to it in [1]. I note that the latest released versions of pep8 and flake8 are not compatible. This situation now persists for several month. For the point of view of a project providing software packaging this is very unsatisfying. In particular, I am referring to Macports here [2]. Such project usually rely on the assumption that the latest released version tend to provide the best quality and user experience of a given software package, and if this should not be the case in one specific moment in time that problems are resolved timely. In the case of pep8 vs. flake8, flake8 imposes constraints on the versions of dependencies. While lower bounds are perfectly fine, the upper bounds are problematic, because a perfectly working and well tested port would break by construction at any time later, when one of its dependencies is updated. I of cause understand the problems involved with parallel developments, but I would argue that one major goal of any project should be to remain compatible with the most recent versions of its dependency when ever possible or to release once major issues are resolved. In the concrete case, it looks like the relevant issue [3], which causes the version constraint on pep8 (>=1.5.7,!=1.6.0,!=1.6.1,!=1.6.2) was actually resolved in [4] already some time ago, but this commit actually not released yet. On the other hand, constraints on mccabe (>=0.2.1,<0.4) & pyflakes (>=0.8.1,<0.9) are not founded on issues with concretely released software [1], but only hypothetical show-stoppers once these versions are effectively released [5]. I'd argue, such constraints shouldn't be around after all, but introduces only after test failure show evidence of any problem. Anyway, if develops want to insist on them [1], these should be relaxed timely after the release the relevant software. For pyflakes the release of version 0.9.0 dates back to 2015-05-31 [6], the release was acknowledged pretty timely in [7] and fixed in [8], but the change was no release thereafter yet. So my question is now when this issues with conflicting versions, can be expected to be solved upstream. This is of particular relevance to understand if and how to solve the downstream issue in Macports [2], and if we need to foresee for any interim solutions. Thank you very much! ~petr --- [1] https://gitlab.com/pycqa/flake8/issues/68 [2] https://trac.macports.org/ticket/47429 [3] https://gitlab.com/pycqa/flake8/issues/35 [4] https://github.com/jcrocholl/pep8/commit/435d1cbf995a659a82d1d4b42d25e3459556ef21 [5] https://trac.macports.org/ticket/47429#comment:4 [6] https://pypi.python.org/pypi/pyflakes/0.9.0 [7] https://gitlab.com/pycqa/flake8/issues/61 [8] https://gitlab.com/pycqa/flake8/commit/f2b0bb52e5dc94da2d0dbdbbe655956228bf1f22 From graffatcolmingov at gmail.com Mon Jun 29 20:43:10 2015 From: graffatcolmingov at gmail.com (Ian Cordasco) Date: Mon, 29 Jun 2015 13:43:10 -0500 Subject: [code-quality] pep8 vs. flake8 incompatibility ... In-Reply-To: <41A0C768-150D-4F36-BCD7-4FD299DDD637@ingv.it> References: <41A0C768-150D-4F36-BCD7-4FD299DDD637@ingv.it> Message-ID: On Mon, Jun 29, 2015 at 1:24 PM, Peter Danecek wrote: > > Dear all, > > I am writing this mail, after I was directed to it in [1]. I note that the latest released versions of pep8 and flake8 are not compatible. This situation now persists for several month. Correct, because pep8 has yet to release a version of software that isn't broken in their 1.6 line. The last reliable version is 1.5.7. 1.6.0, 1.6.1, and 1.6.2 all break fundamental features of pep8 and flake8. > For the point of view of a project providing software packaging this is very unsatisfying. In particular, I am referring to Macports here [2]. Such project usually rely on the assumption that the latest released version tend to provide the best quality and user experience of a given software package, and if this should not be the case in one specific moment in time that problems are resolved timely. The assumption that "the latest is the greatest" isn't always correct. In this particular case that /assumption/ is incredibly wrong. > In the case of pep8 vs. flake8, flake8 imposes constraints on the versions of dependencies. While lower bounds are perfectly fine, the upper bounds are problematic, because a perfectly working and well tested port would break by construction at any time later, when one of its dependencies is updated. Packaging incompatibilities are the packagers concern. Macports should be policing dependencies better than they are if they're having problems with this. From Flake8's perspective, we are ensuring the best user experience by implementing caps. > I of cause understand the problems involved with parallel developments, but I would argue that one major goal of any project should be to remain compatible with the most recent versions of its dependency when ever possible or to release once major issues are resolved. Given enough people working on all of the projects, that is definitely a plausible and realistic goal. That isn't the situation here. If you'd like to lend several hours of development work to all affected projects along with others, I'm sure we could all be perfectly in sync. Until then, please don't tell us volunteers how to spend our time. > In the concrete case, it looks like the relevant issue [3], which causes the version constraint on pep8 (>=1.5.7,!=1.6.0,!=1.6.1,!=1.6.2) was actually resolved in [4] already some time ago, but this commit actually not released yet. > > On the other hand, constraints on mccabe (>=0.2.1,<0.4) & pyflakes (>=0.8.1,<0.9) are not founded on issues with concretely released software [1], but only hypothetical show-stoppers once these versions are effectively released [5]. I'd argue, such constraints shouldn't be around after all, but introduces only after test failure show evidence of any problem. Anyway, if develops want to insist on them [1], these should be relaxed timely after the release the relevant software. For pyflakes the release of version 0.9.0 dates back to 2015-05-31 [6], the release was acknowledged pretty timely in [7] and fixed in [8], but the change was no release thereafter yet. Correct. That will be released in 2.5.0. There are other features and bug fixes planned for 2.5.0 which have not been developed yet. If you look at the issues filed against flake8 you'll notice this. > So my question is now when this issues with conflicting versions, can be expected to be solved upstream. This is of particular relevance to understand if and how to solve the downstream issue in Macports [2], and if we need to foresee for any interim solutions. Code wins. When a release can be prioritized, I'll prioritize it. Unfortunately I cannot prioritize it right now, so feel free to patch your Macports however you like, but please do not call it Flake8. All bugs that are introduced by your downstream patches will not be supported by me. From peter.danecek at ingv.it Mon Jun 29 22:55:20 2015 From: peter.danecek at ingv.it (Peter Danecek) Date: Mon, 29 Jun 2015 22:55:20 +0200 Subject: [code-quality] pep8 vs. flake8 incompatibility ... In-Reply-To: References: <41A0C768-150D-4F36-BCD7-4FD299DDD637@ingv.it> Message-ID: <95189581-1A50-4540-A014-BEE0780EE5AC@ingv.it> Dear Ian, Thanks for your detailed reply! However, I think you have not addressed my final question regarding the timeline of possible releases and having this fixed upstream. I allow myself to add some remarks inline. All the best! ~petr On 29 Jun 2015, at 20:43, Ian Cordasco wrote: > On Mon, Jun 29, 2015 at 1:24 PM, Peter Danecek wrote: >> >> Dear all, >> >> I am writing this mail, after I was directed to it in [1]. I note that the latest released versions of pep8 and flake8 are not compatible. This situation now persists for several month. > > Correct, because pep8 has yet to release a version of software that > isn't broken in their 1.6 line. The last reliable version is 1.5.7. > 1.6.0, 1.6.1, and 1.6.2 all break fundamental features of pep8 and > flake8. > >> For the point of view of a project providing software packaging this is very unsatisfying. In particular, I am referring to Macports here [2]. Such project usually rely on the assumption that the latest released version tend to provide the best quality and user experience of a given software package, and if this should not be the case in one specific moment in time that problems are resolved timely. > > The assumption that "the latest is the greatest" isn't always correct. This is not exactly what I was saying, but I guess you are actually aware of this. You also may have missed the second part of the assumption. > In this particular case that /assumption/ is incredibly wrong. Apparently! This is what I am addressing here ;-) I still believe, projects based on other ones can never have control of everything and need to rely on good practice. >> In the case of pep8 vs. flake8, flake8 imposes constraints on the versions of dependencies. While lower bounds are perfectly fine, the upper bounds are problematic, because a perfectly working and well tested port would break by construction at any time later, when one of its dependencies is updated. > > Packaging incompatibilities are the packagers concern. Macports should > be policing dependencies better than they are if they're having > problems with this. From Flake8's perspective, we are ensuring the > best user experience by implementing caps. Well, this is only partly true. Macports can deal with different versions to some extent, but might do better at verifying Python version constraints. However, I doubt it is worth the effort. MP is not really about Python ports only and real issues are rare. Still, using version constraints extensive has the potential to create conflicts, independently how the package manager deals with it. >> I of cause understand the problems involved with parallel developments, but I would argue that one major goal of any project should be to remain compatible with the most recent versions of its dependency when ever possible or to release once major issues are resolved. > > Given enough people working on all of the projects, that is definitely > a plausible and realistic goal. That isn't the situation here. If > you'd like to lend several hours of development work to all affected > projects along with others, I'm sure we could all be perfectly in > sync. Until then, please don't tell us volunteers how to spend our > time. Thanks for the invitation. However, if time is available I'd probably focus on the projects I am already involved. Of cause, if I find issues with other projects, I am happy to contribute by reporting back, document issues or PR. However, releasing is probably beyond the scope. >> In the concrete case, it looks like the relevant issue [3], which causes the version constraint on pep8 (>=1.5.7,!=1.6.0,!=1.6.1,!=1.6.2) was actually resolved in [4] already some time ago, but this commit actually not released yet. >> >> On the other hand, constraints on mccabe (>=0.2.1,<0.4) & pyflakes (>=0.8.1,<0.9) are not founded on issues with concretely released software [1], but only hypothetical show-stoppers once these versions are effectively released [5]. I'd argue, such constraints shouldn't be around after all, but introduces only after test failure show evidence of any problem. Anyway, if develops want to insist on them [1], these should be relaxed timely after the release the relevant software. For pyflakes the release of version 0.9.0 dates back to 2015-05-31 [6], the release was acknowledged pretty timely in [7] and fixed in [8], but the change was no release thereafter yet. > > Correct. That will be released in 2.5.0. There are other features and > bug fixes planned for 2.5.0 which have not been developed yet. If you > look at the issues filed against flake8 you'll notice this. Looking forward to this! From graffatcolmingov at gmail.com Tue Jun 30 04:10:02 2015 From: graffatcolmingov at gmail.com (Ian Cordasco) Date: Mon, 29 Jun 2015 21:10:02 -0500 Subject: [code-quality] pep8 vs. flake8 incompatibility ... In-Reply-To: <95189581-1A50-4540-A014-BEE0780EE5AC@ingv.it> References: <41A0C768-150D-4F36-BCD7-4FD299DDD637@ingv.it> <95189581-1A50-4540-A014-BEE0780EE5AC@ingv.it> Message-ID: On Mon, Jun 29, 2015 at 3:55 PM, Peter Danecek wrote: > > Dear Ian, > > Thanks for your detailed reply! > However, I think you have not addressed my final question regarding the timeline of possible releases and having this fixed upstream. I should have said explicitly that I've reached out to the pep8 maintainers and received no response, so until then that will continue to be the case (the latest release is broken). As for a release of flake8 2.5.0, I already answered that. When I have time to spend on it, it will be released. > I allow myself to add some remarks inline. > > All the best! > ~petr > > > > > On 29 Jun 2015, at 20:43, Ian Cordasco wrote: > >> On Mon, Jun 29, 2015 at 1:24 PM, Peter Danecek wrote: >>> >>> Dear all, >>> >>> I am writing this mail, after I was directed to it in [1]. I note that the latest released versions of pep8 and flake8 are not compatible. This situation now persists for several month. >> >> Correct, because pep8 has yet to release a version of software that >> isn't broken in their 1.6 line. The last reliable version is 1.5.7. >> 1.6.0, 1.6.1, and 1.6.2 all break fundamental features of pep8 and >> flake8. >> >>> For the point of view of a project providing software packaging this is very unsatisfying. In particular, I am referring to Macports here [2]. Such project usually rely on the assumption that the latest released version tend to provide the best quality and user experience of a given software package, and if this should not be the case in one specific moment in time that problems are resolved timely. >> >> The assumption that "the latest is the greatest" isn't always correct. > This is not exactly what I was saying, but I guess you are actually aware of this. You also may have missed the second part of the assumption. > >> In this particular case that /assumption/ is incredibly wrong. > Apparently! > This is what I am addressing here ;-) > I still believe, projects based on other ones can never have control of everything and need to rely on good practice. What is good practice if not shipping working and quality software that produces reproducible results for users? >>> In the case of pep8 vs. flake8, flake8 imposes constraints on the versions of dependencies. While lower bounds are perfectly fine, the upper bounds are problematic, because a perfectly working and well tested port would break by construction at any time later, when one of its dependencies is updated. >> >> Packaging incompatibilities are the packagers concern. Macports should >> be policing dependencies better than they are if they're having >> problems with this. From Flake8's perspective, we are ensuring the >> best user experience by implementing caps. > Well, this is only partly true. > Macports can deal with different versions to some extent, but might do better at verifying Python version constraints. However, I doubt it is worth the effort. MP is not really about Python ports only and real issues are rare. Still, using version constraints extensive has the potential to create conflicts, independently how the package manager deals with it. > >>> I of cause understand the problems involved with parallel developments, but I would argue that one major goal of any project should be to remain compatible with the most recent versions of its dependency when ever possible or to release once major issues are resolved. >> >> Given enough people working on all of the projects, that is definitely >> a plausible and realistic goal. That isn't the situation here. If >> you'd like to lend several hours of development work to all affected >> projects along with others, I'm sure we could all be perfectly in >> sync. Until then, please don't tell us volunteers how to spend our >> time. > Thanks for the invitation. However, if time is available I'd probably focus on the projects I am already involved. Of cause, if I find issues with other projects, I am happy to contribute by reporting back, document issues or PR. However, releasing is probably beyond the scope. > >>> In the concrete case, it looks like the relevant issue [3], which causes the version constraint on pep8 (>=1.5.7,!=1.6.0,!=1.6.1,!=1.6.2) was actually resolved in [4] already some time ago, but this commit actually not released yet. >>> >>> On the other hand, constraints on mccabe (>=0.2.1,<0.4) & pyflakes (>=0.8.1,<0.9) are not founded on issues with concretely released software [1], but only hypothetical show-stoppers once these versions are effectively released [5]. I'd argue, such constraints shouldn't be around after all, but introduces only after test failure show evidence of any problem. Anyway, if develops want to insist on them [1], these should be relaxed timely after the release the relevant software. For pyflakes the release of version 0.9.0 dates back to 2015-05-31 [6], the release was acknowledged pretty timely in [7] and fixed in [8], but the change was no release thereafter yet. >> >> Correct. That will be released in 2.5.0. There are other features and >> bug fixes planned for 2.5.0 which have not been developed yet. If you >> look at the issues filed against flake8 you'll notice this. > Looking forward to this! > Me too! 2.5.0 is looking to be a good release! Thanks for working on packaging flake8 for macports!