Did you notice these by reading the code or noticed while using the module?

By reading the code. Initially I wanted to only fix cases with PyDict_GetItem() and PyObject_HasAttrString(). Then noticed that exceptions are silenced in other cases, and couldn't stop until analyzed all code that silences or replaces exceptions, and also other suspicious code in the_sqlite3 module.

I think it's better to keep the old code as-is:

Do you mean just this function or all cases in which the only change is inserting a newline before the function name?

I haven't look at the code inmicroprotocols.c recently, so I still need a bit more time to review it and the code relevant to it (e.g.statement.c)

PEP 246 was rejected as a general protocol, but I think it is worth to fix its concrete implementation in sqlite3.

This PR is purposed for the master branch only, because of the chance of breaking user code. But some changes can be backported. I am wondering if it is worth to document and test some user-visible behavior changes. I can split this PR on several parts if you prefer.

Do you mean just this function or all cases in which the only change is inserting a newline before the function name?

I missed thatpysqlite_cursor_init() andpysqlite_cursor_dealloc() were already havestatic keyword. So, let's revert back to the old style in the following functions:

• check_cursor()
• pysqlite_cursor_init()
• pysqlite_cursor_dealloc()

I am wondering if it is worth to document and test some user-visible behavior changes.

I think that would be great if you have time to do so :)

@berkerpeksag, have I addressed all your comments? Could you please take a look at this PR again?

I am going to merge this PR.

Good luck with your move! 🚋✈️ 🚗 🏠 👍