At some point we will need a summary, or to use something better than mailing lists to discuss this. Paul
Paul-Olivier Dehaye SNF Professor of Mathematics University of Zurich skype: lokami_lokami (preferred) phone: +41 76 407 57 96 chat: pauloliv...@gmail.com twitter: podehaye freenode irc: pdehaye On Wed, May 28, 2014 at 9:46 PM, Paul-Olivier Dehaye < paul-olivier.deh...@math.uzh.ch> wrote: > > - Nathann is arguing that no empty methods/classes should be present. > I think he is, and add Vincent too (cf. previous email of his). > > Absolutely noone wants unefficient code. If there is a clear way to > improve, let's do it. But burden is on all of us. > > To be clear, I want to have this semantic information in the code. > > There are many reasons for this, here is one more: it provides an > intermediate step for a person joining sage between a typo fix and > implementing their first function, welcoming microcontributions. I think > decorators would be very suitable for this, but am open to alternate > suggestions. > > > Would this be a short-term solution? > Sure! > > Paul > > > > > > Paul-Olivier Dehaye > SNF Professor of Mathematics > University of Zurich > skype: lokami_lokami (preferred) > phone: +41 76 407 57 96 > chat: pauloliv...@gmail.com > twitter: podehaye > freenode irc: pdehaye > > > On Wed, May 28, 2014 at 8:47 PM, Simon King <simon.k...@uni-jena.de>wrote: > >> Hi Paul, >> >> On 2014-05-28, Paul-Olivier Dehaye <paul-olivier.deh...@math.uzh.ch> >> wrote: >> > Two comments: >> > - Nathann is arguing that no empty methods/classes should be present. >> >> Is he? Sorry, then this is a point where Nathann and I do not agree. I >> find abstract methods useful. I thought that his main point was: Don't >> be intrusive! Do not make code of some people slower just because other >> people care about the mathematical properties of some methods. And from >> my perspective, the discussion is (or should be) only about the >> question: How to care about the mathematical properties without slowing >> down other peoples code. >> >> > - They are not building a database. They are putting tags in the code >> that >> > allow them at runtime to build something that amounts to a database. >> It's >> > not that different to the category framework in some way, which is >> encoding >> > a lot of data via code constructions >> >> There was in fact some discussion at #10963 about the question whether it >> is >> a good idea that the new category-with-axiom framework encodes a >> fully-grown >> would-be-database (by this, I mean something that amounts to a database) >> by >> purely local data and naming conventions. >> >> I'd say: If they are putting tags in the code then they *do* create a >> (would-be-)database, whether they want it or not. >> >> > I am not arguing that what findstat does with a decorator is the best. A >> > flagged decorator that does nothing most of the time is better than what >> > they do. But a full-on database is, as a short term solution, heading in >> > the wrong direction. >> >> Do I understand correctly: You would not like that the >> @combinatorial_map decorator constructs a database at startup time? I >> think that's a valid concern. >> >> We could try to be clever and introduce an environment variable (or >> commandline argument) such that @combinatorial_map creates a database >> when this variable is set, and otherwise does nothing at all. >> >> Hence, people who care about the implicit would-be-database encoded in >> the flags could obtain them by explicit request, and all other people >> would not be affected at all. >> >> Would this be a short-term solution? Also from Nathann's perspective? >> >> Cheers, >> Simon >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sage-combinat-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sage-combinat-devel+unsubscr...@googlegroups.com. >> To post to this group, send email to sage-combinat-de...@googlegroups.com >> . >> Visit this group at http://groups.google.com/group/sage-combinat-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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.