Library code returning int value

[Kwankyu Lee]

Hi,

First of all, it is a bit perplexing to to ask a basic question after working with Sage more than ten years... Anyway here is the question:

When I write Sage library code returning an integer value, is it ok to return `int` or should it always return `Integer`?

If the return value is of type `int`, it is inconvenient to subsequently apply usual methods attached with `Integer` like `factor()`. So I think it is preferable to always return `Integer`.

But I do not find such a policy in the Sage developer manual. So I wonder what is the situation. Which one of the following is true?

(1) No such policy since actually it is a bad policy.

(2) The policy is shared by Sage developers. But no one bothered to write it down in the developer manual.

(3) It is actually in the developer manual. 

(4) There was enough discussion about it in sage-devel. So everyone, except me, knows the right policy.

 

[Nils Bruin]

I'd expect it's (1). A more nuanced version might be:

(5) As a rule, an Integer should probably be returned if the code is probably going to interact with other sage code, but if you have good (efficiency) reasons to prefer a python integer or if the primary function is to be compatible with other python code (such as "len" methods) then returning a python integer should be fine.

The reality is that the "python integer" type interwoven with the language and sage cannot avoid it.

[Travis Scrimshaw]

Perhaps something towards (2) rather than (5), I believe the general principle is to have any method that a "standard" user will encounter to return a Sage Integer. The reasoning is exactly as you mentioned to avoid surprises to the user (e.g., why does "_.factor()" work for "foo" but not for "bar"?).

Best,

Travis

[Kwankyu Lee]

On Monday, July 12, 2021 at 12:44:05 AM UTC+9 Nils Bruin wrote:

I'd expect it's (1). A more nuanced version might be:

(5) As a rule, an Integer should probably be returned if the code is probably going to interact with other sage code, but if you have good (efficiency) reasons to prefer a python integer or if the primary function is to be compatible with other python code (such as "len" methods) then returning a python integer should be fine.

This sounds close to (2) as most of Sage library code is for mathematics. 

Do you or anyone object to include a hint of this policy in the developer manual? 

[David Roe]

I think it's fine to include a discussion of this in the developer's manual: functions should return an integer rather than an int unless there is a good reason not to (mandated by the language for __len__, to reduce overhead for some internal functions).

David

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/553f7cad-3dcc-4a8c-a3c8-916e7b5706d8n%40googlegroups.com.

[TB]

Somewhat similar in spirit, I think that functions should try to return objects of the same type, unless explicitly called with an argument to change such behavior.

It is not just the case of int and Integer. This might happen with Integer vs. Rational, where a function that usually use division, might in certain conditions returns an Integer (or more generally, an element of an integral domain rather than an element of the fraction field).

Of course there is nuance. For example, the 'binomial' function coerce its arguments, or using nullable types when there is a certificate argument, and so on.

Regards,

TB

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAChs6_%3Dm38VsmkqAqv9dMB2%3DSyb%2BfmNPZANrsAcwmG6JacXGww%40mail.gmail.com.

[Kwankyu Lee]

This is now

https://trac.sagemath.org/ticket/32200

[Kwankyu Lee]

While we are at

https://trac.sagemath.org/ticket/32200

which is really about standardizing types of return values. How about including recommendation to prefer `tuple` to `list`? Of course this is only to apply to functions and methods for users. I think it is good to have a default type so that users do not need to check for any reason whether the return value is a tuple or a list.

I dimly remember there was a  discussion about list vs tuple long time ago, but with no conclusion. I don't intend to provoke another discussion. But if we now have reached a consensus on this matter, then we can add it to the ticket.  

[John H Palmieri]

I think that we should prefer tuples to lists when that is appropriate, lists to tuples when that is appropriate. Python has both types for good reasons, I think, and I don't see why we should globally recommend one over the other.

[Kwankyu Lee]

On Thursday, July 15, 2021 at 2:14:20 PM UTC+9 John H Palmieri wrote:

I think that we should prefer tuples to lists when that is appropriate, lists to tuples when that is appropriate. Python has both types for good reasons, I think, and I don't see why we should globally recommend one over the other.

OK. Then we have no consensus on this matter. Thanks.