I confess that I did not understand Nathan's objection, not being familiar with find_stat or the kind of decorator used in that added function. But I myself have added functions to Sage to help a separate project which uses Sage, namely the lmfdb (see http://www.lmfdb.org/). The cost to Sage users who never work with elliptic curves and their labels seems trivial, and it never occurred to me that anyone would object to such functionality.
Perhaps I completely misunderstood though. John On 19 June 2013 21:57, Nathann Cohen <nathann.co...@gmail.com> wrote: >> Everything can be rewritten more efficiently, just at a cost in code size / >> maintainability and human effort. Much like Python itself, decorators are a >> way to make code smaller and easier to read for humans, at a certain >> performance penalty. Don't optimize for speed until profiling showed that >> this is a performance bottleneck. > > I am glad to know that there is a general-purpose rule to tell me that > I should refrain from thinking. I guess that this also answers my > other points about the development model. > > Thank you very much, > > Nathann > > -- > 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 http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/groups/opt_out. > > -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
