> > > The way I see this, *because* of the FindStat use case, the > > combinatorial_map decorator has been introduced and many Sage developers > > have been devoted time into adding semantic information into sage > methods. > > Of course, we could remove this all together, but this would be a great > loss > > for Sage as this semantic information is useful for users. And Here, I > speak > > as a combinatorist person working with these objects every day. > > > > So, our concern should be: how to make this information easily available > to > > users and how could we store this without impacting efficiency of the > > program. > > Dead right ! Is there any reason why gathering this semantic information > requires this decorator to wrap the function in a combinatorial map ? Can't > the information be gathered wherever we need it *without* modifying the > actual function ? You could do whatever you need with a decorator that, > when applied to a function f with some flags, stores a copy of this > function f and works with the flags while returning the original function > f, can't you ? > > This would make it less intrustive, and actually not intrusive at all ! > > Yes, this is a solution that I have repeated to Viviane in Montreal. The objection to that solution (while we were in Edinburgh) was that it would quickly make sense to them to add a bunch of empty classes and functions then. Since, the transition to git has made part of that workflow better for the findstat people.
Paul -- 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.
