I have just added a pyflakes plugin to the patchbot. For the moment, not in a released patchbot, but available by pulling the patchbot master branch.
Frederic Le dimanche 6 mai 2018 18:07:41 UTC+2, Maarten Derickx a écrit : > > A big +1 on adding a "plain old rule-based lint" like pyflakes to the > testsuite. > > On Wednesday, 2 May 2018 20:03:24 UTC+2, Erik Bray wrote: >> >> On Wed, May 2, 2018 at 4:41 PM, John Cremona <john.c...@gmail.com> >> wrote: >> > On another python project I contribute to (LMFDB) we have for some >> time >> > only merged commits which satisfy pyflakes 100%. It's a much smaller >> > project than Sage, and when we first started using pyflakes there was >> quite >> > a lot of work to do, some of which seemed rather unnecessary, but also >> a lot >> > of actual and potential bugs were discovered and fixed. >> > >> > Doing the same to Sage would also be a huge amount of work if all done >> at >> > once, but it could be done incrementally (*). In fact, I already use >> > pyflakes to examine Sage course files I am working on and slip in some >> > changes it prompts as well as everything else in the patch. >> > >> > I know that there are many such tools out there and am not proposing >> using >> > any of them in particular, just reporting on one situation where the >> result >> > was positive and where LMFDB developers would not want to put the clock >> > back. This has nothing to do with algorithmic efficiency. >> >> Indeed--at some point I plan to start running pyflakes over Sage. A >> lot of stuff is getting fixed up in the process of implementing the >> Python 3 support, but that should be the primary focus first. Later, >> adding a per-commit pyflakes check will be easy. >> >> > (*) For example in src/sage/schemes/elliptic_curves/*.py there are >> "only" >> > 138 lines of output from pyflakes now almost all of which would be >> trivial >> > to fix (things imported but not used, variables assigned to but not >> used -- >> > which can be an indication of a typo giving a bug. You also see >> > "ell_curve_isogeny.py:1672: undefined name 'InputError'" which I >> already >> > fixed as part of https://trac.sagemath.org/ticket/23222 . >> > >> > On 2 May 2018 at 14:21, Peter Luschny <peter....@gmail.com> wrote: >> >> >> >> >> >> rjf> The chance that Machine Learning AI programs will find >> >> rjf> important algorithmic efficiency fixes in algebraic >> >> rjf> mathematical implementations seems pretty slim. >> >> >> >> Improving code is something other than improving algorithmic >> >> efficiency of high-level algorithms, of whatever kind. The >> >> latter is certainly not an option yet. But as soon as such >> >> tools look simultaneously on written and compiled code new >> >> opportunities will arise. >> >> >> >> rjf> On the other hand, if you have gobs of code written by high >> >> rjf> school summer interns just learning Python, it is possible >> >> rjf> their code is filled with non-idiomatic and inefficient >> >> rjf> constructions that might be detected/repaired. >> >> >> >> The assumption that only the inexperienced beginner makes >> >> stupid mistakes or writes optimizable code is not likely to be >> >> shared here. But if, as you can seemingly imagine, such can >> >> be pointed to by checkers/optimizers, then the level of >> >> experience of the coder obviously does not matter. >> >> >> >> Between these two extremes are the daily necessaries of the >> >> programmer, and that is what it is all about. In this respect >> >> I find Volker's answer informative and revealing at the same >> >> time. >> >> >> >> vb> First we should add one of the plain old rule-based linters >> >> vb> to our testsuite, imho that would go a long way of maintaining >> >> vb> a consistent code style (and avoid trivial review friction). >> >> >> >> I have expected a lot of people answering Volker: "Hey, you >> >> are right, after the next release let's introduce such tools >> >> before we continue." >> >> >> >> Since such answers did not come in I gladly admit to having >> >> asked the question in the wrong place and at the wrong time. >> >> >> >> The question for me remains whether this reluctance towards >> >> such tools is typical for open-source/academic projects. >> >> Interestingly also Volker writes only about 'code style', not >> >> of other forms of improvements. I have the impression that >> >> the situation in the industry is quite different. >> >> >> >> rjf> It's your choice how to spend your time. Is it worth a try? >> >> >> >> You are absolutely right. I don't know any plausible estimate >> >> that the programming time developers spend for debugging is >> >> less than 50%; many estimates are significantly higher. But >> >> that's an old hat. >> >> >> >> P. >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups >> >> "sage-devel" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> an >> >> email to sage-devel+...@googlegroups.com. >> >> To post to this group, send email to sage-...@googlegroups.com. >> >> Visit this group at https://groups.google.com/group/sage-devel. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "sage-devel" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to sage-devel+...@googlegroups.com. >> > To post to this group, send email to sage-...@googlegroups.com. >> > Visit this group at https://groups.google.com/group/sage-devel. >> > For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
