I am not sure it is purely about Python types since it gets changed into C
code. (For reference, I changed your snippet to cpdef and got the same
result too.) It would be nice if there was an actual specification for
this in Cython. I just get slightly worried after getting translated into C
code, it then depends on the compiler.
Anyways, such changes should be fine (this was my initial reaction too)
except in perhaps very extraordinary circumstances...
Best,
Travis
On Monday, February 26, 2024 at 1:34:31 AM UTC+9 Nils Bruin wrote:
> Hi Travis,
>
> No, these routines are about the python types. They get used as `type(x)
> is int` and `type(x) is long`. They are used in a different namespace from
> `cdef int x` and `cdef long x` and cdef long long x` (well, the `x` is in
> the cython object namespace. The C-types don't make it into the cython
> object namespace. They are in a C type namespace).
>
> The cython test routine above confirms that the objects `int` and `long`
> (not the cdef type names!) are indeed the same object in cython
> The code below confirms they are the python `int` type object:
>
> sage: cython("""
> ....: def test(x):
> ....: return (x is long, x is int)
> ....: """)
> sage: test(int)
> (True, True)
> On Sunday 25 February 2024 at 01:48:09 UTC-8 Travis Scrimshaw wrote:
>
>> Sorry for the delayed response.
>>
>> If the C compiler can't tell the difference between an int and a long,
>> then that suggests that there is still a difference. I am not sure that
>> Cython has any specification that these are different. My understanding is
>> Cython treats these as C types. Can we be certain that an int that is not a
>> long will not find its way in? Could it also depend on someone's version of
>> C/Python?
>>
>> Best,
>> Travis
>>
>>
>> On Thursday, February 22, 2024 at 2:52:25 PM UTC+9 Nils Bruin wrote:
>>
>>> 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/0f6ec32b-68ff-425b-81a7-05cc75e72013n%40googlegroups.com.
