Hi Minh, Thanks for carefully investigating those:
> > sage/monoids/monoid.py > > I think this module should stay put. Here is a dependency chart based > on that module: > > monoids.monoid.Monoid_class --> monoids.free_monoid.FreeMonoid_class > --> monoids.string_monoid.StringMonoid_class > > where the relation > > a --> b > > means that a is used by b. From > monoids.string_monoid.StringMonoid_class, various alphabets are > defined. These alphabets are extensively used in various cryptography > modules, e.g. > > * crypto/classical_cipher.py > * crypto/classical.py > * crypto/cryptosystem.py > * crypto/stream_cipher.py > * crypto/util.py > * crypto/public_key/blum_goldwasser.py > * crypto/block_cipher/miniaes.py > * crypto/block_cipher/sdes.py Right now your are right ! However if you read the doc, it says that it should be removed after making a proper use of categories... So it should be deprecated in the long run... > > sage/structure/element_py.py > > I have looked through that file and have doctested the Sage > 4.4.4.alpha0 library with that file removed. So far no failures, which > doesn't mean that structure/element_py.py isn't used anywhere else. One more indication: there isn't any reference to element_py anywhere in sage: tomahawk-*el/sage-combinat $ grep element_py **/*.py* Fichier binaire build/sage/structure/element_py.pyc concorde > Indeed, a complaint with strong language. But you get the general idea > about having good documentation. For reference, I have collected some > resources [2] on how to write good documentation. Sure !!! You don't need to convince me. > > sage/structure/element_verify.py > > I get the feeling that this module is about code analysis for Cython > modules. I think it might come in handy later on when someone needs to > write a code analysis framework. They might not use all of > structure/element_verify.py, but I suspect that that module could > provide a starting point on how to proceed. It seems to me completely redudant with the TestSuite/category framework. Once again let's keep it until things got adapted to those framework. > > sage/misc/typecheck.py > > As with structure/element_py.py, the module misc/typecheck.py just > makes me feel stupid when it comes time for me to try to use it. A > tool that makes one feel stupid isn't making a good impression on that > person, and would drive the person away from using it. To me, the > module is very under-documented, doesn't follow PEP 008 coding > conventions, and very badly formatted. I let others in the Sage > community form their own judgements about the removal of this module. > > > > This remark also hold for the following typecheck function in > > sage/misc/misc.py > > ################################################################# > > # Type checking > > ################################################################# > > def typecheck(x, C, var="x"): > > """ > > Check that x is of instance C. If not raise a TypeError with an > > error message. > > """ > > if not isinstance(x, C): > > raise TypeError, "%s (=%s) must be of type %s."%(var,x,C) > > This looks to me like, how can I put it, redundant code. I'm basing my > judgement on the idea that I would write such code at the point where > I want to do sanity checking, instead of calling a function that does > the same thing, but doesn't allow me to customize my exception > message. I would personally vote for removal of this function. Let's wait for more vote... Cheers, Florent -- 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
