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/c6fe238f-9640-4c97-a861-d56fe6e87494n%40googlegroups.com.
