Hi Nicolas, I have to confess that I didn't really appreciate that I was deprecating these functions from the global name space but in any case I am in favour of doing so, so +1.
Patch #13072 deprecates such functions in favour of the cardinality method of the corresponding partition class. The patch also removes many functions, like partitions_list, which were deprecated a long time ago and so shouldn't be in use any more -- this seems to be the problem that posets/poset_examples.py is having. In fact, many of the functions that #13072 removes were deprecated just in the doc strings, which probably means that they were deprecated well before the now deprecated initial deprecation framework was put in place! Consequently, their flagged deprecation didn't show up when the code was tested. Apologies for not asking everyone if they liked this idea...I thought that these were obvious clean ups that had to happen, and that everyone would just agree...I guess that I am too used to developing my own code in isolation. Sorry! If everyone agrees that this is a good idea then I will add deprecation warnings into sage.combinat.all. If the we vote to keep them then I'll reinstate the global names in the patch. In terms of the functions in doctests etc the best fix would be to change them so that use Partition(n).cardinality() etc. Again, I would hunt these down and fix them if people are in favour of deprecation. By the way, number_of_partitions is one of the few such functions that I didn't deprecate in partition.py. The reason for this is that this function is wrapped in a cached_function call and I didn't want to break this... I suspect that if simply put a cached_method decorator on Partition.cardinality() then this would have the same effect but as I wasn't sure I left it well enough alone. Is this true? Best regards, Andrew On Thursday, 23 August 2012 20:11:57 UTC+10, Nicolas M. Thiery wrote: > > Hi Andrew, > > I just noticed that with your patch > trac_13072-tuples-of-partitions_am.patch > quite a few functions, like ``number_of_partitions`` are not imported > by default any more in the interpreter name space. > > On the principle, I personally like this, as it goes toward having a > single entry point for features about partitions (namely Partitions), > which reduces the pollution of the interpreter name space. But others > may like those shortcuts. So please vote your preference here: > > [ ] Do not import number_of_partitions and friends any more > [ ] Keep things as they currently are in Sage > > Now, if we indeed go for not importing number_of_partitions, we > probably need to deprecate this import, using something like: > > in sage.combinat.partitions: > > def number_of_partitions_deprecated(n): > ... deprecation message: please use Partitions(n) instead ... > return number_of_partitions(n) > > in sage.combinat.all: > > from partition import number_of_partitions_deprecated as > number_of_partitions > > Also, we need to update a few doctests in the sage sources that use > this function and will now need to import it (see > sage.misc.superseded, sage.misc.cachefunc). > > See also the related failures in sage.combinat.posets.hasse_diagram, > sage/combinat/posets/poset_examples. > > Cheers, > Nicolas > -- > Nicolas M. Thi�ry "Isil" <nth...@users.sf.net <javascript:>> > http://Nicolas.Thiery.name/ > -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To view this discussion on the web visit https://groups.google.com/d/msg/sage-combinat-devel/-/xQ93oikIZpgJ. To post to this group, send email to sage-combinat-devel@googlegroups.com. To unsubscribe from this group, send email to sage-combinat-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/sage-combinat-devel?hl=en.
