Idea: Treat all NULLs as None #416

Activity

1. cjdoris

   added this to the v1 milestone on Nov 7, 2023
2. cjdoris commented on May 31, 2026

   

   cjdoris

   on May 31, 2026

   MemberAuthor

   More actions

   I quite like this idea - it seems good for safety.

   • What's the performance impact of the constant NULL checking?
   • Where should the boundary be? Could implement it in getptr? Or in the C wrapper functions? Or what?
   • Or can we just avoid NULLs entirely and actually always just have the ptr be None?
     • That is, pynew() should return None not NULL.
     • But pynew(ptr) just wraps the given pointer.
     • How does pydel! work in all of this? It needs to eagerly free the python object. So it SHOULD set the ptr to null.
3. cjdoris

   changed the title [-]Treat all NULLs as None?[/-] [+]Idea: Treat all NULLs as None[/+] on May 31, 2026
4. cjdoris commented on May 31, 2026

   

   cjdoris

   on May 31, 2026

   MemberAuthor

   More actions

   Alternatively, we could remove NULLs from the API entirely. We already recommend using const foo = Ref{Py}() rather than const foo = pynew() in top-level package code.
5. cjdoris commented on May 31, 2026

   

   cjdoris

   on May 31, 2026

   MemberAuthor

   More actions

   For example, unsafe_pynext() could be removed. Instead have a method pynext(x, d) which returns d when there are no more items. For example pynext(iter, nothing) would return nothing (rather than a python NULL).
6. cjdoris commented on May 31, 2026

   

   cjdoris

   on May 31, 2026

   MemberAuthor

   More actions

   #783 adds pynext(x, d) so we can just deprecate unsafe_pynext.
7. cjdoris commented on Jun 4, 2026

   

   cjdoris

   on Jun 4, 2026

   MemberAuthor

   More actions

   Ok we've removed the unsafe API - Py objects are not NULL in the API. So this issue is irrelevant now.
8. cjdoris

   closed this as completedon Jun 4, 2026