Re: [sage-devel] @options() decorators in sagemath library code and Sphinx 7.1+

2023-09-16 Thread Michael Orlitzky
On 2023-09-16 14:09:04, Dima Pasechnik wrote: > > Anyhow, if this is the only problem with upgrading to Sphinx 7.1+ (or 8) > it ought to be fixed, so that we can move on on Sphinx update. > (see https://github.com/sagemath/sage/pull/35658) My vote would be to replace the weird sageism with the

Re: [sage-devel] @options() decorators in sagemath library code and Sphinx 7.1+

2023-09-16 Thread Dima Pasechnik
On Sat, Sep 16, 2023 at 1:39 PM Michael Orlitzky wrote: > > On Sat, 2023-09-16 at 13:16 +0100, Dima Pasechnik wrote: > > Isn't it true that the above may be simplified, removing foo=bar from > > @options() and putting this in the function definition, i.e. > > > > AFAIK it's just dictionary

Re: [sage-devel] @options() decorators in sagemath library code and Sphinx 7.1+

2023-09-16 Thread Michael Orlitzky
On Sat, 2023-09-16 at 13:16 +0100, Dima Pasechnik wrote: > Isn't it true that the above may be simplified, removing foo=bar from > @options() and putting this in the function definition, i.e. > AFAIK it's just dictionary unpacking that happens by default. You can already create your own options

[sage-devel] @options() decorators in sagemath library code and Sphinx 7.1+

2023-09-16 Thread Dima Pasechnik
We have instances of @options() (from src/sage/misc/decorators.py) applied to functions in the library, e.g. https://github.com/sagemath/sage/blob/41031292ff1ae518cd5b5a29ce277aa1ff8ced9e/src/sage/plot/contour_plot.py#L1394 where an argument name of the form foo=bar in @options matches an