[sage-devel] Re: Global options

[Andrew Mathas]

On Saturday, 13 April 2013 20:16:37 UTC+10, Volker Braun wrote:

> So whats global in GlobalOptions? Presumably the instance options are the 
> same as the global options, just with a different scope? Is that 
> implemented? 
>

Yes, you are right, there is nothing intrinsically global in them and it is 
just how they are used that determines their scope. The name is just an 
artefact of how the class evolved. 
 

> Shouldn't we give every parent then options() / global_options() for 
> consistency?
>

I don't see an obvious way of automatically generating sensible options for 
an arbitrary parent. If this was wanted then perhaps the default should 
simply be to define options for _repr_ and _latex_ as "dispatchers". This 
would provide element classes with a generic interface for overriding the 
default implementations of _repr_ and _latex_ with user-defined functions. 
This probably wouldn't be too painful to implement.

Andrew

-- 
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.

[sage-devel] Re: Global options

[Volker Braun]

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.

[sage-devel] Re: Global options

[Andrew Mathas]

On Friday, 12 April 2013 19:23:31 UTC+10, Volker Braun wrote:
>
> It would be nice if we could implement the syntax in the IPython 
> configuration stuff:
>
> A.options.foobar = 1
>
> in addition to
>
> A.options(foobar=1)
>
> This would require us to rename the existing methods of GlobalOptions with 
> underscores. 
>

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

The methods in red are all "standard" SageObject methods which probably 
should not be renamed.


> Also, for consistency we should recommend / enforce a name for the 
> options. Should it be A.options or A.global_options or what? The docs use 
> various conventions.
>

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.

Andrew

-- 
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.

[sage-devel] Re: Global options

[Volker Braun]

It would be nice if we could implement the syntax in the IPython 
configuration stuff:

A.options.foobar = 1

in addition to

A.options(foobar=1)

This would require us to rename the existing methods of GlobalOptions with 
underscores. 

Also, for consistency we should recommend / enforce a name for the options. 
Should it be A.options or A.global_options or what? The docs use various 
conventions.




On Friday, April 12, 2013 2:17:35 AM UTC+1, Andrew Mathas wrote:
>
> Dear Developers,
>
> As part of the clean up of the partitions code by Travis (Trac 
> 13605) 
> I implemented a generic options interface in sage which can be used for 
> controlling (global) options for sage objects. See 
> sage.structure.global_options for details. This patch, including the 
> global_options, was merged in sage-5.8.beta3. 
>
> Novosel has just complained, quite justifiably, on the ticket above that 
> the global options should have been given their own ticket rather than 
> being hidden in a large patch. Apologies for this, but these options just 
> grew as part of my review patch with fine tune-tuning (and reviewing) from 
> Travis and Nicolas at ICERM... 
>
> Given the obscure manner in which this options framework has entered sage, 
> and Novosel's comment on the ticket, I now take the opportunity to 
> advertise them.
>
> Andrew
>

-- 
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.

[sage-devel] Re: Global options

[Andrey Novoseltsev]

Thanks for the advertisement (and for implementing it in the first
place!), here is a link to compiled documentation for those who are
interested:

http://sagemath.org/doc/reference/structure/sage/structure/global_options.html#sage.structure.global_options.GlobalOptions

-- 
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.