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
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.
On Wednesday, July 14, 2021 at 7:21:48 PM UTC-7 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
This is now
https://trac.sagemath.org/ticket/32200
--
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 view this
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,
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
On Mon, Jul 12, 2021 at 3:26 AM
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
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
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
