Re: [sage-devel] Re: Is there a math alternative to range and interval?

On Friday, October 19, 2018 at 10:16:28 AM UTC+9, William wrote: > > > > (4) is this "range" the vanilla python built-in? > > Yes. Type "range??" in Sage to see. > Right. I didn't know that range first converts the argument to int, which is why "range(Integer(10))" works. By the way, I am

[sage-devel] Re: Is there a math alternative to range and interval?

Thanks for your inputs. Let me summarize: ellipsis notation: gives a list of Integers sage: [0..9] [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] sage: preparse('[0..9]') '(ellipsis_range(Integer(0),Ellipsis,Integer(9)))' sage: type([0..9].pop()) ZZ.range: gives a list of integers sage: ZZ.range(10) [0, 1,

[sage-devel] Is there a math alternative to range and interval?

Hi, I am teaching sage to a class of first year math students. Today I was embarrassed when I tried [i.is_prime() for i in range(1,10)] because this raises an error. Until this point, I deliberately did not mention that there are in fact two kinds of "integers" in sage and avoided to

[sage-devel] Re: bug in printing matrices

I see no garbage in jupyter notebook with sage 8.4.beta1 on mac. -- 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

[sage-devel] Re: No signature shown for methods

Thanks for the discussion. This is now #26254. https://trac.sagemath.org/ticket/26254#ticket -- 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] No signature shown for methods

Hi, I wonder why help on a method does not show the signature: --- sage: a=17 sage: a.quo_rem? Docstring: Returns the quotient and the remainder of self divided by other. Note that the remainder returned is always either zero or of the same

[sage-devel] Re: talk

Charming slides! I could sympathize with most of your wishlist. Many thanks that you started Sage project, around the time when I wished something like Sage! -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and

[sage-devel] Re: Poll about adopting matplotlib2 style for Sage graphics

Now it is time to close the poll. Counted from 8 participants to the discussion, there are 5 positive votes; 2 no opinion; 1 not-so-positive vote. Thank you! -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group

[sage-devel] Re: Release schedule survey

+1 to B. B can be more flexible if only the next release day is announced (on sage-release) when a new sage is released, and if the release day may be delayed on the release manager's discretion. -- You received this message because you are subscribed to the Google Groups "sage-devel" group.

Re: [sage-devel] Poll about adopting matplotlib2 style for Sage graphics

General description of the differences between the classic style and the matplotlib2 default style (that we are now going to adopt) is found in https://matplotlib.org/users/dflt_style_changes.html -- You received this message because you are subscribed to the Google Groups "sage-devel" group.

[sage-devel] Re: Poll about adopting matplotlib2 style for Sage graphics

+1 for me :-) I also want to mention my motivation for the ticket: Enabling customization via matplotlibrc is important for me because I want to use a Korean font for text. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from

[sage-devel] Poll about adopting matplotlib2 style for Sage graphics

Hi, This ticket https://trac.sagemath.org/ticket/25799 is about removing the classic style hardcoded to all sage graphics rendered by matplotlib. The hardcoding happened in trac #23696 as people disliked some aspects of the new default style of matplotlib2. It seems that people disliked

Re: [sage-devel] Matplotlib plotting style 'classic' hardcoded to Sage

Consulting https://matplotlib.org/users/dflt_style_changes.html we may keep specifically only the math font of the classic style by: mpl.rcParams['mathtext.fontset'] = 'cm' mpl.rcParams['mathtext.rm'] = 'serif' and adopt the default matplotlib-2 style generally. I assume that the

Re: [sage-devel] Matplotlib plotting style 'classic' hardcoded to Sage

Yeah, I found one thing that looks ugly on my machine: In the 'classic' style: In the current default style: -- 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

Re: [sage-devel] Matplotlib plotting style 'classic' hardcoded to Sage

On Monday, July 9, 2018 at 10:40:03 AM UTC+9, François Bissey wrote: > > I am sorry to have introduced that in the upgrade to matplotlib 2.1. > Hardcoding > was easier than setting the style to classic for every calls for the > documentation. > The reports I had was that the default style

[sage-devel] Matplotlib plotting style 'classic' hardcoded to Sage

Hi, This ticket https://trac.sagemath.org/ticket/25799 aims to remove matplotlib style 'classic' hardcoded into Sage. This makes customization through the matplotlibrc file work, which fails presently. After the ticket merged, the default matplotlib styles would be applied to all Sage

[sage-devel] Re: Re: ceil or ceiling?

On Saturday, June 9, 2018 at 2:53:56 AM UTC+9, John H Palmieri wrote: > > > On Friday, June 8, 2018 at 7:59:39 AM UTC-7, Marc Mezzarobba wrote: >> >> >> Personally, I'd vote for keeping ceil(), and not adding any alias. >> > > I agree with this. Another philosophy (at which Sage should do a

Re: [sage-devel] ceil or ceiling?

> > Yes and no. I would rather keep ceil to be the default and ceiling to > be an alias. It is more complient with mathematical libraries, > programming languages, etc. > In a sense, I like the philosophy of Mathematica, where Ceiling[x] is standard. I thought Sage shares the same

Re: [sage-devel] ceil or ceiling?

On Friday, June 8, 2018 at 8:50:48 PM UTC+9, vdelecroix wrote: > > On 08/06/2018 08:21, Dima Pasechnik wrote: > > ceil() is a standard Python function. > > Thus, Sagemath has to live with it. > > Not only Python. It is C standard function > from math.h. Also GMP, MPFR, etc does use ceil and

[sage-devel] Re: ceil or ceiling?

On Friday, June 8, 2018 at 6:23:51 PM UTC+9, Samuel Lelievre wrote: > > > > Fri 2018-06-08 06:21:45 UTC, Dima Pasechnik: > > > > ceil() is a standard Python function. > > Thus, Sagemath has to live with it. > > If we look at object methods rather than functions > in the global namespace, it is

[sage-devel] ceil or ceiling?

Hi, I always thought there are "floor" and "ceiling" functions in math. But in Sage, {{{ sage: ceil(pi) 4 sage: floor(pi) 3 sage: ceiling(pi) --- NameError Traceback (most recent call last)

[sage-devel] Re: random_element and randtest_element

> > What do you think? Does the name randtest_element look ok? How about "_random_test_element", as this method needs not to be revealed to users, unlike "random_element" and "some_elements". -- You received this message because you are subscribed to the Google Groups "sage-devel" group.

[sage-devel] Review request for global function fields into Sage

Hi, I am in the process of bringing global function field machinery into Sage. But the process is getting too slow. You can help me by reviewing the ticket https://trac.sagemath.org/ticket/24591 There is not much mathematics in the ticket, and whoever has looked at the function field code of

[sage-devel] Re: Block TermOrder equality is broken

On Thursday, March 15, 2018 at 9:59:44 AM UTC+9, Nils Bruin wrote: > > On Thursday, March 15, 2018 at 12:44:39 AM UTC, Kwankyu Lee wrote: >> >> Hi, >> >> Which part of the output you consider wrong? Would you elaborate on the >> "incorrect behaviour&quo

[sage-devel] Re: Block TermOrder equality is broken

Hi, Which part of the output you consider wrong? Would you elaborate on the "incorrect behaviour"? Kwankyu -- 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] Re: Asking for advice: differential operators in the global namespace

> > Is it OK to introduce five new names in the global namespace: > grad, div, curl, laplacian, dalembertian > and possibly a sixth one: rot as an alias of curl? > -1 > An alternative (disapproved by the reviewer) is to inject these names in > the global namespace only if any

[sage-devel] Re: nbextensions on jupyterlab

On Sunday, March 4, 2018 at 1:17:40 AM UTC+9, mmarco wrote: > > Thanks, I finally could solve it with a dirty hack: > > I put the nbextensions inside /usr/local/share/jupyter/hub/static/ > I did the same. > jupyterhub does serve files that are located there > Right, at /hub/static/. So I

[sage-devel] Re: nbextensions on jupyterlab

On Friday, March 2, 2018 at 12:30:29 AM UTC+9, mmarco wrote: > > I am trying to install a service to use Sage through the jupyterlab > frontend, behind a jupyterhub server. > > So far, I could get everything to work, even the threejs interactive > graphics on a standalone jupyterlab instance.

[sage-devel] Re: jsmol broken on JupyterHub

On Wednesday, January 27, 2016 at 12:47:58 AM UTC+9, Volker Braun wrote: > > It doesn't work right now; The kernel doesn't know whether it is running > under jupyter or jupyterhub. > After lots of trial and errors, I managed to make sagemath work under Jupyterhub. One cause of constant

Re: [sage-devel] replace is_X functions

The rationale of removing "is_X(Z)" should be for consistency, not that it is implemented simply as "isinstance(Z, X_type)". I would assume "is_X(Z)" are mostly math questions, either simple or hard. I don't want to use "isinstance" to ask a math question. So +1 for moving toward deprecating

[sage-devel] Re: Another build error

On Saturday, December 9, 2017 at 5:10:51 AM UTC+9, Simon King wrote: > > Hi Travis, > > On 2017-12-07, Travis Scrimshaw wrote: > > IMO, a better practice is to merge in old branches to a branch based off > > develop. If you want to rebase, then run rebase. That way you

[sage-devel] Re: Another build error

On Friday, December 8, 2017 at 8:30:48 AM UTC+9, Travis Scrimshaw wrote: > > > >> Anyway. The branch used to be an old one. I checked it out and then >> rebased on top of the latest develop. Do I understand correctly that >> while rebasing, git failed to remove the cypari2 folder? >> >> IMO,

Re: [sage-devel] dicts in doctests

> > Users should be able to run the EXAMPLES and see what we say they'll see. > +1 -- 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] Re: matrix group action on elements of a subspace

On Saturday, November 25, 2017 at 6:42:03 PM UTC+9, Simon Brandhorst wrote: > > > However, that file was created in 2007, and it is almost not documented at > all. > Is it the way to go anyways? > This is a usual motivation that a sager contributes back to Sage development. If you see some

Re: [sage-devel] Coercion about finite field extensions, again

This is now https://trac.sagemath.org/ticket/24195 I regard this behavior as a bug. -- 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] Re: Development tasks

> > I saw that there is work on supporting python 3. Is there more that needs > doing on that? > Desperately. Follow this: https://trac.sagemath.org/ticket/15530 -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group

Re: [sage-devel] Coercion about finite field extensions, again

On Thursday, November 9, 2017 at 6:17:41 PM UTC+9, John Cremona wrote: > > On 9 November 2017 at 00:50, Kwankyu Lee <ekwa...@gmail.com > > wrote: > > Hi, > > > > From a discussion last year, I know that creation of finite fields with > > generator na

[sage-devel] Coercion about finite field extensions, again

Hi, >From a discussion last year, I know that creation of finite fields with generator names is different from without generator names. But still the following is counter-intuitive. sage: k=GF(4) sage: K=k.extension(3, name='a') sage: k.is_subring(K) False sage: L=k.extension(3) sage:

Re: [sage-devel] python3 status

On Saturday, October 14, 2017 at 6:51:01 PM UTC+9, John Cremona wrote: > > How can we be sure that new code witten by people (like me) who are > not python2/3 experts does not regress? This would help. While coding on Sage, I refer to Python 3 reference manual :-) -- You received this

Re: [sage-devel] semantic of equality for Graph/Digraph

On Thursday, August 31, 2017 at 12:41:26 AM UTC+9, Jeroen Demeyer wrote: > > On 2017-08-30 09:37, david@inria.fr wrote: > > It's not a bug, it's how equality is defined > > Thinking of the coercion model, I would argue that this is a bug. > It is not a bug as it behaves as documented.

Re: [sage-devel] RFC: Draft blog post on Sage for Windows

Great work! > Some more typos: * plots will saved -> plots will be saved * (HAV) to enabled -> (HAV) to be enabled * should be considered a service -> should be considered as a service -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

[sage-devel] Re: Ergodic Theory

On Friday, July 28, 2017 at 1:04:37 AM UTC+9, Travis Scrimshaw wrote: > > ... it is very easy to develop new code within Sage directly. I do this > all the time, and sometimes this is the only way because you need to modify > some parts of Sage. It also makes it easier to submit it to trac,

Re: [sage-devel] What to do with the "Timed out" failures of patchbots?

It was noted that the issue might be related with that discussed in https://groups.google.com/forum/#!searchin/sage-devel/linbox$2064-bit$20charpoly%7Csort:relevance/sage-devel/TLcYb4z7jyI/SsW02-5mBwAJ -- You received this message because you are subscribed to the Google Groups "sage-devel"

Re: [sage-devel] What to do with the "Timed out" failures of patchbots?

+1 This seems the best workaround for now as it would take some time to fix the root cause of these timeouts. On Monday, July 10, 2017 at 11:57:19 AM UTC+2, Erik Bray wrote: > > On Fri, Jul 7, 2017 at 4:25 PM, Kwankyu Lee <ekwa...@gmail.com > > wrote: > > Hi, > &

[sage-devel] Re: What to do with the "Timed out" failures of patchbots?

I ran the same for i in `seq 0 1000` ; do sage -t --long src/sage/graphs/matchpoly.pyx ; done and most of the runs takes about 5 seconds but there are exceptionally long runs. A typical one of them is: sage -t --long --warn-long 75.3 src/sage/graphs/matchpoly.pyx Timed out

[sage-devel] Re: What to do with the "Timed out" failures of patchbots?

On Sunday, July 9, 2017 at 7:10:37 AM UTC+2, Ralf Stephan wrote: > > (5) Test manually not once but 10 times since the long runs may not happen > in 100% of all runs > Could you ever reproduce the long run ("Timed out") by repeating standalone testing? I suspect the long run happens in the

Re: [sage-devel] What to do with the "Timed out" failures of patchbots?

I observed another "Timed out" on a patchbot: sage -t --long src/sage/graphs/matchpoly.pyx Timed out On my laptop, this takes just less than 5 seconds. Strange... -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

Re: [sage-devel] What to do with the "Timed out" failures of patchbots?

> > (4) Actually investigate why the tests time out so often > Ok. For example, sage -t --long src/sage/plot/plot.py takes about 90 seconds on my laptop machine, but strangely the same testing apparently takes more than 30 minutes on some patchbot machine. This is not fully explained by

[sage-devel] Re: What to do with the "Timed out" failures of patchbots?

On Friday, July 7, 2017 at 4:38:14 PM UTC+2, Volker Braun wrote: > > (4) Try to find out why these tests time out and fix the underlying issue > Isn't the issue is that the tests in the file actually take more time in total than the limit set by SAGE_TIMEOUT_LONG, especially when the machine

[sage-devel] What to do with the "Timed out" failures of patchbots?

Hi, Nowadays, it seems frequent that patchbots report "Timed out" failures. The files "plot.py" and "test.py" are often to blame. These patchbot reports are false in the sense that the ticket that is tested is not the cause of the failure. What should we do? I can think of three options (1)

Re: [sage-devel] About milestone sage-feature

> > > This will be a pain to manage. These branches will go stale very quickly > > and rebasing will be a frustrating chore. If you have programs that you > > don't want to install in sage proper, then just maintain them as a > > python package with sage as a dependency and put the source on

Re: [sage-devel] About milestone sage-feature

> > Maybe sage-feature branches don't get merged > because they are too optimistic, too much work, adding a feature that > nobody cares about... > I am thinking of feature branches that are fully implemented but not expected to be merged to sage soon because it is too special, too big,

[sage-devel] About milestone sage-feature

Hi, As one who added the latest of the tickets with milestone sage-feature, I want to enliven them. As I see it, a sage-feature ticket intends to provide a sage feature branch that is not appropriate to be merged to Sage through the normal review process, but still useful to the people

[sage-devel] Re: Patchbot monitoring

On Friday, June 30, 2017 at 9:54:00 AM UTC+2, Erik Bray wrote: > > Does anyone who runs / administers Sage patchbots have any hints/tips > regarding monitoring of their patchbots? > I run a patchbot using screen. 1. I use "screen -r" to see what the patchbot is doing currently. 2. I check

Re: [sage-devel] src/ext and unsafe tickets

> > Coincidentally, I just discovered this feature myself in the process > of preparing a little patch to the patchbot. This could be really > sluggish for the Windows patchbot, so I'll probably just disable it in > the settings. The feature (allowing to test unsafe tickets) seems broken

[sage-devel] src/ext and unsafe tickets

Hi, If a patch to a ticket put files in src/ext, then the ticket is considered "unsafe", and the patchbot treat it with caution. In particular, the patchbot clones sage into /tmp and builds it with the patch there. This causes the building time (and the size of the log file) increase

[sage-devel] Global function fields in Sage

Hi, I am maintaining a Sage feature branch on global function fields at https://trac.sagemath.org/ticket/22982 I welcome your feedback. Enjoy! Kwankyu -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop

[sage-devel] Please review #23017: specifics of docstrings

There is no more comment on the ticket https://trac.sagemath.org/ticket/23017 Would someone review the ticket, before we forget our consensus? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

[sage-devel] Re: Option for docbuilding without plots?

I did not make any efforts to confirm but I have the following impression from my experiences. The docs with plots are rebuilt even though there was no direct change by me and this anomaly disappears with the patch at https://trac.sagemath.org/ticket/22588. -- You received this message

[sage-devel] Re: Report on the results of the polls for specific guidelines for docstrings

There is no more comment on the ticket https://trac.sagemath.org/ticket/23017 Would someone review the ticket, before we forget our consensus? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

[sage-devel] Re: Sage Python 3 proposal

> > I also thought about building both py2+3 at the same time, it would be a > great debugging help during the transition if you can easily run both. Then > in 3 years we'll just cut out the py2 part and be done with it... > I am thinking of what would be the real benefits, compared with the

[sage-devel] Re: Brainstorming about Sage dependencies from system packages

I wonder if the recent discussion of possible schemes about how to build Sage for python 2 and 3 (one may propose (or object to) that Sage should be built to be runnable both for python2 and python3) could be related with your proposal. Is it simply orthogonal with your proposal or somehow

[sage-devel] Re: No highlights in the release notes

> > Perhaps it would be possible to have, in addition to the compulsory AUTHOR > and REVIEWER fields, in sage-trac a new optional field HIGHLIGHTS, that > the > author can fill with some text if (s)he believes the ticket is worth it > The text should be refined, unlike the others that we

Re: [sage-devel] Re: No highlights in the release notes

On Friday, May 26, 2017 at 7:10:43 AM UTC+2, Jori Mäntysalo wrote: > > How many developer does something to highlight **in a particular > release**? > I don't know. But who knows before we ask developers? > As an example, I could put something like this for 8.0: > > - Finite lattices now

[sage-devel] Re: No highlights in the release notes

On Thursday, May 25, 2017 at 10:46:22 PM UTC+2, Sébastien Labbé wrote: > > For some time, Minh was writing highlighted release notes. Here is the > last one I found of him (already 8 years ago): > > https://mvngu.wordpress.com/2009/08/22/sage-4-1-1-released/ > > Wow, that is a great historic

[sage-devel] Re: python3 : help needed

The successful launch with my built of sage with python3 seems well explained by John. On Thursday, May 25, 2017 at 5:37:10 PM UTC+2, Frédéric Chapoton wrote > > The road towards a full python3 sage is still quite long, and my > motivation gets weaker, as it seems that not so many people care

[sage-devel] Re: python3 : help needed

On Thursday, May 25, 2017 at 4:36:04 PM UTC+2, Frédéric Chapoton wrote: > > Very surprising that sage starts.. Did you really launch the sage that you > just compiled ? > I suspect this as well... I will respond later when I am sure about everything. I am a bit busy for other things right

[sage-devel] Re: python3 : help needed

On Thursday, May 25, 2017 at 10:49:34 AM UTC+2, Frédéric Chapoton wrote: > > ok, now with 8.0.b8, you can just do > > "export SAGE_PYTHON3=yes" > > and then "make build". This should succeed, with no error message. > > Then try "./sage" > Following your instructions, I built sage on mac. Then

[sage-devel] No highlights in the release notes

Hi, The most powerful ever, a new beta, Sage 8.0.beta8, was just released. But as always, it is rather dull to look through the "release note". It would be good that there are "highlights" selected from the many ticket descriptions. An author of a ticket might want to advertise the ticket by

[sage-devel] Report on the results of the polls for specific guidelines for docstrings

Dear developers, Thank you for your participation for the polls (and discussions) on guidelines for docstrings. Now I close the polls and summarize the result: H1, H3, H4, H6 got affirmative votes from most of you. H2 did not get affirmative votes from most of you as it is stated in the

Re: [sage-devel] Second round poll for H5 a specific guideline for writing docstrings

On Monday, May 22, 2017 at 2:41:17 PM UTC+2, vdelecroix wrote: > > > Yes! A function in Python always return a unique object. This object > might be a tuple or a list with several components. Ok. Now I understand how you view things. I always thought it is a common idiom in Python that when

Re: [sage-devel] Second round poll for H5 a specific guideline for writing docstrings

It seems that some misunderstanding is going on here. If a method returns an integer and a matrix by "Return n, m". I am saying that the output block can be simply OUTPUT: - integer ... - matrix ... instead of OUTPUT: a tuple of ``(n,m)`` where - ``n`` is a integer ... - ``m`` is a matrix

Re: [sage-devel] Second round poll for H5 a specific guideline for writing docstrings

On Monday, May 22, 2017 at 12:08:35 PM UTC+2, Jeroen Demeyer wrote: > > On 2017-05-22 12:05, Kwankyu Lee wrote: > > My opinion is that the phrase "a tuple `(a,b,c)` where ..." is just > > redundant. > > I think that "a tuple" is important non-

Re: [sage-devel] Second round poll for H5 a specific guideline for writing docstrings

On Monday, May 22, 2017 at 10:24:32 AM UTC+2, Jeroen Demeyer wrote: > > I very much object to this: > > > If the output consists > > of several items, add each starting with a hyphen. > > If the output consists of several items, the OUTPUT string should > clearly mention that fact (and it

Re: [sage-devel] Re: Second round poll for H2 a specific guideline for writing docstrings

This is my last attempt to save the guideline. A Sage user has an integer X. He hit the tab key and get "X.is_prime", and then ask what this method does by entering "X.is_prime?". Imagine that he reads (1) Return whether the integer is prime. (2) Return whether this integer is prime. (3)

[sage-devel] Re: Second round poll for H5 a specific guideline for writing docstrings

+1 H5 is intended to be conforming with "INPUT:" block. The above example is somewhat misleading. If the output is just a "tuple of lattices" (without long additional explanation), then the entire OUTPUT block can be omitted since the one-liner can be "Return a tuple of lattices that ".

Re: [sage-devel] Second round poll for H2 a specific guideline for writing docstrings

> > Here is my opinion. But a metaquestion: Why can't someone (like Kwankyu) > just got direct emails and make a summary? > Hmm. Just to make the result of the voting transparent to everyone. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To

[sage-devel] Re: Secondl round poll for H6 a specific guideline for writing docstrings

+1 In English, I understand that "foo; bar" is used if "bar" gives additional information about "foo" while "foo, bar"is used to list "foo" and "bar" on equal level. But I am not a native speaker... -- You received this message because you are subscribed to the Google Groups "sage-devel"

[sage-devel] Re: Second round poll for H4 a specific guideline for writing docstrings

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

[sage-devel] Re: Second round poll for H3 a specific guideline for writing docstrings

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

[sage-devel] Re: Second round poll for H2 a specific guideline for writing docstrings

+1 The point is that "the lattice" (or a slight variant "this lattice") is officially recommended than "``self``". -- 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

[sage-devel] Re: Second round poll for H1 a specific guideline for writing docstrings

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

[sage-devel] Re: Second round poll for H2 a specific guideline for writing docstrings

As some of you worry, I do not attempt to put some strict rules into the developer manual so that forbid your own style in writing docstrings. These are intended just as guidelines; these will guide him or her when a developer is in doubt in styling the docstrings. On the other hand, if you

[sage-devel] Secondl round poll for H6 a specific guideline for writing docstrings

Hi, I prepared H6 from your comments on the style of INPUT block. It was hard to make a compromise from your differing opinions and reach a proposal for the better. So this time* if I fail to get approval from most of you, the guideline will be simply discarded.* ** H6. Write INPUT: -

[sage-devel] Second round poll for H5 a specific guideline for writing docstrings

Hi, I prepared H5 revised from G5 based on your ideas and wishes. It was hard to make a compromise from your differing opinions and reach a proposal for the better. So this time* if I fail to get approval from most of you, the guideline will be simply discarded.* ** H5. Write OUTPUT:

[sage-devel] Second round poll for H4 a specific guideline for writing docstrings

Hi, I prepared H4 revised from G4 based on your ideas and wishes. It was hard to make a compromise from your differing opinions and reach a proposal for the better. So this time* if I fail to get approval from most of you, the guideline will be simply discarded.* ** H4. OUTPUT block is

[sage-devel] Second round poll for H3 a specific guideline for writing docstrings

Hi, I prepared H3 revised from G3 based on your ideas and wishes. It was hard to make a compromise from your differing opinions and reach a proposal for the better. So this time* if I fail to get approval from most of you, the guideline will be simply discarded.* ** H3. Write Return

[sage-devel] Second round poll for H2 a specific guideline for writing docstrings

Hi, I prepared H2 revised from G2 based on your ideas and wishes. It was hard to make a compromise from your differing opinions and reach a proposal for the better. So this time* if I fail to get approval from most of you, the guideline will be simply discarded.* ** H2. Write if the

[sage-devel] Second round poll for H1 a specific guideline for writing docstrings

Hi, I prepared H1 revised from G1 based on your ideas and wishes. It was hard to make a compromise from your differing opinions and reach a proposal for the better. So this time* if I fail to get approval from most of you, the guideline will be simply discarded.* ** H1. Write ``True``,

Re: [sage-devel] Re: About oneliners in TOC vs. docstring

On Thursday, May 18, 2017 at 10:59:35 AM UTC+2, vdelecroix wrote: > > On 18/05/2017 10:33, Jori Mäntysalo wrote: > > On Thu, 18 May 2017, Kwankyu Lee wrote: > > > >> is_sectionally_complemented() | Return True if every interval > >> from the b

[sage-devel] Re: About oneliners in TOC vs. docstring

> > > However, in the index I use > > is_sectionally_complemented() | Return True if every interval from the > bottom is complemented. > I would write: is_sectionally_complemented() | Test if every interval from the bottom is complemented. -- You received this message because you are

Re: [sage-devel] Poll for issue G1 a specific guideline for writing docstrings

> > -1 > > See the first few lines of [1] where an equivalent of our ``True`` is > used (and therefore written in typewriter font) > (This is perhaps my last resistance; please bear with me :-) A technical question: is it possible to set our Sphinx so that we write in a docstring Return

Re: [sage-devel] Poll for issue G5 a specific guideline for writing docstrings

> OUTPUT: a tuple ``(a,b)`` with > > - ``a`` a foo > > - ``b`` a bar > How about this? We can avoid making up variables. (1) OUTPUT: tuple of - foo; friend of bar - bar; friend of foo or simply (2) OUTPUT: - foo; friend of bar - bar; friend of foo - -- You

[sage-devel] Poll for issue G5 a specific guideline for writing docstrings

We do a poll for adopting an official guideline for docstrings (see https://trac.sagemath.org/ticket/23017) G5. Write OUTPUT: - lattice but do not write OUTPUT: lattice The development manual says a hyphen is optional. But for consistency, we need to settle down on

[sage-devel] Poll for issue G4 a specific guideline for writing docstrings

We do a poll for adopting an official guideline for docstrings (see https://trac.sagemath.org/ticket/23017) G4. OUTPUT block is optional The developer manual says OUTPUT block is not optional. But I think the first statement of the docstring "Return an object ..." already

[sage-devel] Poll for issue G3 a specific guideline for writing docstrings

We do a poll for adopting an official guideline for docstrings (see https://trac.sagemath.org/ticket/23017) G3. Write (1) Return True if the lattice is reflexive. but do not write (2) Return True if the lattice is reflexive and False otherwise. nor (3) Return whether the lattice is

[sage-devel] Poll for issue G2 a specific guideline for writing docstrings

We do a poll for adopting an official guideline for docstrings (see https://trac.sagemath.org/ticket/23017) G2. Write if the lattice is reflexive ... but don't write if ``self`` is reflexive ... If you agree, flag +1; if you disagree and want it reversed, flag -1; if you

[sage-devel] Poll for issue G1 a specific guideline for writing docstrings

We do a poll for adopting an official guideline for docstrings (see https://trac.sagemath.org/ticket/23017) G1. Write Return True if something is true. but do not write Return ``True`` if something is true. The same applies to `False` and `None` If you agree, flag +1; if

Re: [sage-devel] Several choises for docstring

Now we have a ticket for this https://trac.sagemath.org/ticket/23017 Please add your issues to the ticket, following its explicit style :-) -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails

Re: [sage-devel] Re: Unifying "test::" and "tests::"

> > I agree; in the formatteed text, there should not be quotes, In terminal and jupyter, ``True`` is rendered "True". I think this is ugly. It should be rendered True > but it should also not be formatted as plain text. Why not? Why do we treat them differently from other Sage objects?

<    1   2   3   4   5   6   7   8   >