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 <[email protected] > <javascript:>> 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 <[email protected] <javascript:>> > 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 [email protected] <javascript:>. > >> To post to this group, send email to [email protected] > <javascript:>. > >> 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 [email protected] <javascript:>. > > To post to this group, send email to [email protected] > <javascript:>. > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
