Hi Nicolas,
On 2016-04-14, Nicolas M. Thiery wrote:
> So now we have (at least) the following proposals:
>
> 1. a decorator applying to the full docstring
> 2. a markup applying to everything below in the docstring (e.g. .. OPTIONAL::
> gap)
> 3. a markup applying to a single block of code
> 4.
Hi Jeroen,
On 2016-04-14, Jeroen Demeyer wrote:
> On 2016-04-14 00:00, Simon King wrote:
>> If I understand correctly, such a decorator would not work in Cython code.
>
> Why not? Cython supports decorators.
I occasionally got errors telling me that Cython does not support
arbitrary decorators.
Hi Martin,
On 2016-04-13, 'Martin R' via sage-devel wrote:
> A thought: it might in fact be a feature that tab completion *does* show
> methods which only work with optional packages. I usually try
> tab-completion first. I won't mind at all hitting an error message "Please
> install the opt
On 2016-04-12, Nicolas M. Thiery wrote:
> On the other hand I am frustrated with the tone of sage-devel these
> days. I would really appreciate if e-mails would acknowledge others
> efforts; something like "thanks for the suggestion and for
> investigating how to implement it".
+1
> I am not goi
On Monday, April 11, 2016 at 11:43:46 PM UTC+1, Volker Braun wrote:
>
> IMHO thats terrible; When you copy&paste an example it should either work
> or say very clear why it is optional.
>
I disagree. I remember that when my students saw sage documentation for the
first time they did not understan
On Mon, Apr 11, 2016 at 03:43:46PM -0700, Volker Braun wrote:
>IMHO thats terrible; When you copy&paste an example it should either
>work or say very clear why it is optional.
>Just having some magic marker somewhere in the documentation,
>long before the example starts, is potentia
Hi Nicolas,
On 2016-04-11, Nicolas M. Thiery wrote:
> At Sage Days 77, we discussed introducing a docstring-wide markup that
> would be equivalent to adding # optional on all the following
> doctests.
Hooray! I have long been waiting for such a markup, but didn't know how
to implement it myself!
I think there are two issues: one is how the docstring should be written,
and the other is how it should be printed, either via introspection or in
the reference manual. So with this proposal, the reference manual could
have those blocks nicely delineated, as Nicolas said, to suggest caution
wh
IMHO thats terrible; When you copy&paste an example it should either work
or say very clear why it is optional. Just having some magic marker
somewhere in the documentation, long before the example starts, is
potentially much more confusing than the visual clutter of repeated magic
comments cou
