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.