Hey everyone, On Thursday, January 31, 2013 4:54:52 AM UTC-5, Volker Braun wrote: > > I don't think we want to add decorators to each method. In fact, I > definitely don't :-)
I agree. Plus how would this work with optional/variable-length arguments? (Also it gets away from the weakly typed nature of Python.) A saner approach would be to leverage our existing doctests. Just go > through the AST and see which methods are being called directly in > doctests. Then, as you execute the doctests, save the types of the > arguments into a database. Would be a fun undergrad project... > > Hmm...However we should make sure it is after a `__classcall__()`, for example in the crystals code, lots of input is of the form `CrystalOfTableaux(['A', 4], shape=[3,2,2,1]) and what we are after is not two lists, but a CartanType (although the actual datatype you get depends on the letter and ideally we'd want to hide this) and a partition. I guess in these complicated cases a decorator, some kind of docstring hook (such as :inputtype:`Integer`) or manually enter data into a table would be a way to do it... ...Actually what if we did that as a first pass, but from then onwards, we (i.e. whomever would be doing this) would go back and do the (likely small) number of corrections. Plus we would display the data from the database as part of the documentation and when we build the doc, any classes or functions which did not have an entry in the database would run the first pass (unless it used a decorator/datatype hook). Although this would increase development time (I doubt by much in general), and it would mean we'd have to get doctest coverage for all *public *functions to 100%... > On Thursday, January 31, 2013 9:29:26 AM UTC, Harald Schilly wrote: > When I saw it, I liked that it doesn't rely on javascript (ok, well, > formula rendering), and had a linear top-down layout (by accident). This > led me to the conclusion that it could also be a suitable as simplified > interface for mobile devices! Of course, the current features would be just > a small part, but it's quite obvious, that an object with an easy-to-scroll > list of methods and attributes is much easier to use than having to type in > anything. It's also much more accessible to novice users … If we use the stored database approach, we can also add additional data associated to each type and/or input, such as what type of widget it should be, min/max values, etc. This would make any web/mobile interface much easier/faster to construct and seems fairly flexible to me. Best, Travis -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
