On Wed, Apr 13, 2016 at 10:56:48AM -0700, mmarco wrote:
>I was thinking of something much deeper, something like:
>@optional('eggs')
>def spam():
>"""
> docstring with the corresponding doctests
>"""
>blah
>And then, several things happen:
> 1. The
That would be awesome! In fact, within emacs (sage-mode) I also get all
the underscored methods, which I don't like at all. I should ask about
that...
Am Mittwoch, 13. April 2016 23:12:37 UTC+2 schrieb mmarco:
>
> That's a valid point. Maybe there is a middle option that could combine
> the b
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.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop recei
Then "OPTIONAL - foo" gets the same status with "EXAMPLES" (or "INPUT",
"OUTPUT", etc). This conveys a misconception since "OPTIONAL" does not mean
anything with the method or function that this docstring is attached to.
I prefer Dima's suggestion or some variant of that.
--
You received this
I think that having an optional Sphinx block is a good idea. Perhaps it
could be colored differently in the html documentation (like WARNING blocks
are)? When printing on the command line, I think we're just used to the
#optional tag. It's unclear to me whether the #optional tag or an OPTIONAL
b
Hi Marco,
Am Mittwoch, 13. April 2016 19:56:48 UTC+2 schrieb mmarco:
>
>
> @optional('eggs')
> def spam():
> """
>docstring with the corresponding doctests
> """
> blah
>
>
If I understand correctly, such a decorator would not work in Cython code.
Best regards,
Simon
--
You rec
Am Mittwoch, 13. April 2016 19:22:12 UTC+2 schrieb Volker Braun:
>
> Or just call the block OPTIONAL, so that
>
> EXAMPLES::
>
> sage: bar() # optional - foo
> sage: baz() # optional - foo
>
> is equivalent to
>
> OPTIONAL - foo::
>
> sage: bar()
> sage: baz()
>
I like that p
That's a valid point. Maybe there is a middle option that could combine the
best of both worlds: is it possible to tweak tab-completion in such a way
that certain functions are printed in different colors?
El miércoles, 13 de abril de 2016, 22:07:28 (UTC+2), Martin R escribió:
>
> A thought: it
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 optional package Foo" if it saves me an hour of internet
search, fiddli
On Wed, 13 Apr 2016, mmarco wrote:
@optional('eggs')
And then, several things happen:
2. On startup, the function `spam` is defined only if the package `eggs` is
installed. In particular, tab completion would only show it if the
package is installed.
That would be extremely nice.
I was thinking of something much deeper, something like:
@optional('eggs')
def spam():
"""
docstring with the corresponding doctests
"""
blah
And then, several things happen:
1. The testing framework ignores the doctests for the function
`spam`only if the package `eggs`
On Tuesday, April 12, 2016 at 1:48:17 PM UTC+2, Dima Pasechnik wrote:
> perhaps a meaningful compromise would be test-wise #optional tags, per
> test/example or per test/example block
>
Or just call the block OPTIONAL, so that
EXAMPLES::
sage: bar() # optional - foo
sage: baz() #
Hi Miguel,
On Wed, Apr 13, 2016 at 03:05:56AM -0700, mmarco wrote:
>Sorry if I sounded rude or disrispectful, It wasn't my intention at
>all.
No worry, I know :-)
>Let me try to redeem myself by proposing some constructive proposal:
Thanks!
>what about a function/method
Sorry if I sounded rude or disrispectful, It wasn't my intention at all.
Let me try to redeem myself by proposing some constructive proposal: what
about a function/method level mark (be it a decorator or a comment)?
It could have more benefits than just treating correctly the doctests. It
coul
On Tue, Apr 12, 2016 at 09:14:44PM +0200, 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 implemen
On Tue, Apr 12, 2016 at 02:03:15AM -0700, mmarco wrote:
>I agree with Volker here. If the problem is that writing a
># optional blah
> at the end of each line that starts with
>sage:
> maybe limited to a certain portion of your file, that sounds like the
>kind of thing
On Tuesday, April 12, 2016 at 8:37:53 AM UTC+1, Jeroen Demeyer wrote:
>
> On 2016-04-12 00:04, Nicolas M. Thiery wrote:
> > Dear Sage developers,
> >
> > It's quite common that optional doctests come in batch, typically when
> > documenting a method that is only available when a cert
I agree with Volker here. If the problem is that writing a
# optional blah
at the end of each line that starts with
sage:
maybe limited to a certain portion of your file, that sounds like the
kind of thing you could easily do with some simple plugin for your
favourite text editor. Or
On 2016-04-12 00:04, Nicolas M. Thiery wrote:
Dear Sage developers,
It's quite common that optional doctests come in batch, typically when
documenting a method that is only available when a certain feature or
package is available.
Let me add something here: often, not *every* test req
On 2016-04-12 00:04, Nicolas M. Thiery wrote:
Dear Sage developers,
It's quite common that optional doctests come in batch, typically when
documenting a method that is only available when a certain feature or
package is available. Having to mark each and every test line with
`# optional
Dear Sage developers,
It's quite common that optional doctests come in batch, typically when
documenting a method that is only available when a certain feature or
package is available. Having to mark each and every test line with
`# optional xxx` is redundant, painful, and harms readabilit
21 matches
Mail list logo
