On Jun 11, 2010, at 2:33 AM, Florent Hivert wrote:
Hi Minh,
They all looks like they should be deprecated and removed... If
it's true I
rather improving the doctest coverage by removing them than adding
doctests... However I'd like to have the confirmation that they
are indeed
obsolete...
We are aiming for a Sage 5.0 release. The major version number says
it: don't expect backwards compatibility. So whatever functions,
methods, classes, modules that are deprecated should be removed in
Sage 5.0. Now it's time to take stock of deprecated stuff that are
over 60 months old and plan to remove them. Let's be brutal wherever
we can :-)
This brings up an orthogonal issue--if we're going to try to get lots
of publicity for 5.0, wouldn't it be better to focus on stability than
use the chance to break backwards compatibility?
I like this way of seeing. However, I was speaking about module or
functions
which are not tested nor deprecated and nowhere used into sage (easy
to check
using grep). Does it make sens to remove them without a deprecation
warning ?
Many code seems to had been put here, just in case it is useful, and
was never
used by the sage lib itself, but maybe by some users...
Do we agree on the policy:
- If a user need a code, he should take care to document and test it.
- Corollary: any code which is not tested, nor used can be safely
removed
without a deprecation warning.
The only code without doctests is (should be) old code that went in
before the 100% doctest policy, so I don't think we can just go and
delete things like this (especially really old code, which often but
not always has lots of stuff sitting on top of it.)
sage/monoids/monoid.py
I'm pretty sure this is actually used.
sage/structure/element_py.py
Deprecate for sure.
sage/structure/element_verify.py
Probably deprecate, putting any relevant functionality into the
coverage script.
sage/misc/typecheck.py
This was added just last version? Perhaps ask the author Dmitry
Dvoinikov.
Note that just deleting a file and running tests isn't sufficient, as
one would have to purge the .py and .pyc (or .so) files from all the
build directories as well.
- Robert
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
