I tried removal here:
https://github.com/sagemath/sage/pull/37420
and as expected it looks like it's working fine.

On Wednesday 21 February 2024 at 19:06:50 UTC-8 Nils Bruin wrote:

> well, I don't expect the C compiler to be smart enough to recognise the 
> second is an "elif False:", so the "hurt" would be in additional code 
> executed. Plus, having hidden "elif False:"s in a code base is a really bad 
> code smell, so I think there is a penalty. What do you want to guard 
> against? "int" and "long" becoming not synonyms in cython again? There will 
> be probably other py2/3 relics in our code base. I think we should clean 
> them up when encountered, unless we have a good reason not to.
>
> On Wednesday 21 February 2024 at 17:55:48 UTC-8 Travis Scrimshaw wrote:
>
>> I think so, but it might not hurt to have it.
>>
>> Best,
>> Travis
>>
>> On Thursday, February 22, 2024 at 9:54:32 AM UTC+9 Nils Bruin wrote:
>>
>>> I noticed the following cython code
>>>
>>>         if S is long:
>>>             return sage.rings.integer.long_to_Z()
>>>         elif S is int:
>>>             return sage.rings.integer.int_to_Z()
>>>
>>>
>>> https://github.com/sagemath/sage/blob/30fecca1981087a88eb8db2cf05e18edbb50d16f/src/sage/rings/integer_ring.pyx#L589C1-L593C1
>>>
>>> However, in cython with python3 we now have:
>>>
>>> sage: cython("""
>>> ....: def tst():
>>> ....:     return int is long
>>> ....: """)
>>> sage: tst()
>>> True
>>>
>>> so I think the `elif` can be deleted. Is that correct?
>>>
>>

-- 
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 discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c1bc68c4-8b5a-47f1-9a53-39528aa852b4n%40googlegroups.com.

Reply via email to