On Fri, May 25, 2012 at 9:39 AM, Vincent Delecroix <20100.delecr...@gmail.com> wrote: >> Potential workarounds: >> >> - Accept things as they are: that's just a corner case, it's easy for >> the user to fix the name after the import >> - Accept strings like "cached_method" as input as well as names for >> those cases > > I like it better. But that way there is no better method than parsing > for finding its module! > >> - Find some heuristic for those cases (usually the lower case is >> preferred to the upper case?) > > Nope. It really depends. Some funny guy may write "integer_ring = > IntegerRing()" somewhere. > >> Anyway, we should not waste too much time on that. > > +1 > > The last version of the patch seems better (it corrects the from > 'sage.all import ZZ' into 'from sage.rings.integer_ring import ZZ' but > keeps the problem of CachedMethod vs cached_method).
What about allowing the user to pass "cached_method" (as a string) to import_statements? > Note that the option verbose should perhaps be True by default? +1. The user should be aware that there are other possibilities, and hopefully will pick accordingly. Perhaps print a blankline after the warnings so that it is easy to distinguish the warnings from the blank lines? Franco -- -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. 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.
