Add NULL checks after PyTuple_Pack calls to prevent potential errors

[sourcery-ai]

The codebase currently lacks NULL checks after calls to PyTuple_Pack, which can return NULL on error. This issue poses a bug risk as it can lead to unexpected behavior or crashes if the error is not handled properly.

The specific instance mentioned is in the code where PyTuple_Pack is used without checking for a NULL return value. The suggested fix is to add a NULL check immediately after the PyTuple_Pack call, as follows:

PyObject *tuple = PyTuple_Pack(2, path, retval);
if (tuple == NULL) {
    return NULL;
}

Additionally, there are other files such as kvitems_basecoro.c and parse_basecoro.c that also lack these checks. It is recommended to perform a comprehensive review and update all instances where PyTuple_Pack is used without a NULL check across the codebase. A separate commit addressing all these instances would be beneficial to ensure consistency and robustness in error handling.

---

I created this issue for @wodny from #127 (comment).

Tips and commands

Interacting with Sourcery

• Generate a plan of action: Comment @sourcery-ai plan on this issue.
• Generate a pull request for this issue: Comment @sourcery-ai develop to
  generate a PR that addresses this issue.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[rtobar]

I'm responding to a bot just so any future readers are aware. This is annoyingly and pedantically correct; however I'm not particularly concerned about it at this stage. This codebase is pretty battle-tested already, and therefore I presume the main reason a tuple would fail to be created is because we're OOM, in which case many other things are bound to fail as well.

Happy to leave it in the back-burner.

[rtobar]

At the end I did end up addressing these PuTyple_Pack calls. However, and more importantly, this led me to check our usage of the PyTuple_* API across the board, and I ended up:

1. Switching to use the non-checking APIs for PyTuple and PyList (e.g., PyList_GET_ITEM), which increased the performance of parse by ~4% locally (48f98b7), and
2. Adding further checks to the input values for the send methods of the parse/kvitems/items generators in the C backend (7bfd322) to ensure we get two- or three-tuples, and generate the appropriate errors if not (mimicking what target-list assignments like a, b = c do).