would it be easy to have the patchbots run such a tool? if so, one could at least have the information, without being forced to do anything.
Martin Am Mittwoch, 2. Mai 2018 16:41:48 UTC+2 schrieb John Cremona: > > 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. > > John > > (*) 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 <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 sage-devel+...@googlegroups.com <javascript:>. >> To post to this group, send email to sage-...@googlegroups.com >> <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 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.
