On 24 Apr., 01:18, Florent Hivert wrote:
> > I mostly agree on that. We just have to get rid of Sphinx. > flame>
>
> Or rewrite it in Cython !!! Please Do !!!
If only I had the time... (although I wouldn't use Cython I think)
> > > I had people asking me how to check if an element is in a set
On 24 Apr., 01:18, Florent Hivert wrote:
> > I mostly agree on that. We just have to get rid of Sphinx. > flame>
>
> Or rewrite it in Cython !!! Please Do !!!
I
>
> > > I had people asking me how to check if an element is in a set and
> > > complaining that it is not written in the documentatio
> I mostly agree on that. We just have to get rid of Sphinx. flame>
Or rewrite it in Cython !!! Please Do !!!
> > I had people asking me how to check if an element is in a set and
> > complaining that it is not written in the documentation. Well, the
> > reasonable search on a doc page is for "
On 23 Apr., 23:49, Andrey Novoseltsev wrote:
> On Apr 23, 3:22 pm, leif wrote:
>
> > Adding docstrings to such functions (or improving existing ones) is
> > orthogonal to including them into the HTML or PDF documentation in
> > general.
>
> I'd also say that docbuild time, documentation size, and
Hi Andrey,
> I'd also say that docbuild time, documentation size, and amount of
> necessary memory are orthogonal to (not) adding special methods to the
> documentation.
I totally agree.
> I am not saying that they are irrelevant, but if we hit
> limits on these the solution is perhaps to
On Apr 23, 3:22 pm, leif wrote:
> Adding docstrings to such functions (or improving existing ones) is
> orthogonal to including them into the HTML or PDF documentation in
> general.
I'd also say that docbuild time, documentation size, and amount of
necessary memory are orthogonal to (not) adding
On 2012-04-23 23:22, leif wrote:
> Same here. I wouldn't say that +38 MB (or +21.5%) is "a bit"; it also
> multiplies with the number of Sage installations.
Also: how much memory do we need to *build* the documentation?
Currently (i.e. without this change), Sage needs about 2.5GB to build
the docu
On 23 Apr., 12:05, Florent Hivert wrote:
> This is a second question: It seems that several Sage developers consider
> Python's (``.__*__``) and Sage's (``._*_``) *special* methods as public so
> that they should be included in the doc by default. On the opposite, *private*
> methods starts by ``_
On Apr 23, 9:39 am, Florent Hivert wrote:
> On Mon, Apr 23, 2012 at 08:29:47AM -0700, Andrey Novoseltsev wrote:
> > [x] use the Sphinx automethod standard trick.
> > [ ] use a special Sage attribute "_included_private_doc_"
>
> > [ ] leave things as they are and rely on the preceding "automethod"
On Mon, Apr 23, 2012 at 08:29:47AM -0700, Andrey Novoseltsev wrote:
> [x] use the Sphinx automethod standard trick.
> [ ] use a special Sage attribute "_included_private_doc_"
>
> [ ] leave things as they are and rely on the preceding "automethod" or
> "_included_private_doc_" trick to documen
[x] use the Sphinx automethod standard trick.
[ ] use a special Sage attribute "_included_private_doc_"
[ ] leave things as they are and rely on the preceding "automethod" or
"_included_private_doc_" trick to document special methods.
[x] include __*__ and _*_ method by default in the doc.
Wi
Florent Hivert writes:
> [ ] use the Sphinx automethod standard trick.
> [ ] use a special Sage attribute "_included_private_doc_"
No opinion.
> [ ] leave things as they are and rely on the preceding "automethod" or
> "_included_private_doc_" trick to document special methods.
> [ ] inc
12 matches
Mail list logo
