On Saturday, April 13, 2013 4:36:47 AM UTC+1, Andrew Mathas wrote: > One advantage of this is of course would be tab-completion for the > options. I'm not entirely sure about renaming the existing methods, > however. The methods for a GlobalOptions object are currently: > > category, db, default_value, dispatch, dump, dumps, rename, reset, > reset_name, > save, version >
Does GlobalOption benefit from subclassing SageObject? Which category is it in? Whats the purpose of the rename method? This is not an object that makes a lot of sense on its own, so why should it be on the same footing as mathematical objects that you commonly generate on the Sage command line? In any case you'd need to override __dict__ or __dir__ to make the A.options.foobar tab-completion work, so you could just as well hide useless methods. Though perhaps it would be best to not put in useless methods to start with. > I see two different use cases: > > - global options which control the general behaviour of one or more > classes (as with the currently implemented global_options methods of > Partitions, Tableaux, PartitionTuples, ...) > - options which control how particular instances of class function > > Encouraging global_options for the former and options for the latter would > make sense > So whats global in GlobalOptions? Presumably the instance options are the same as the global options, just with a different scope? Is that implemented? Shouldn't we give every parent then options() / global_options() for consistency? -- 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.
