[issue43094] sqlite3 signature discrepancies between documentation and implementation

Erlend Egeberg Aasland added the comment: > Of course! I may be not be able to respond to you quickly in the next few > weeks, though. Thank you! I'll send you a preliminary version sometime this week. -- ___ Python tracker

[issue43094] sqlite3 signature discrepancies between documentation and implementation

Berker Peksag added the comment: > Berker, I started drafting a PEP. Would you be interested in helping? Of course! I may be not be able to respond to you quickly in the next few weeks, though. -- ___ Python tracker

[issue43094] sqlite3 signature discrepancies between documentation and implementation

Erlend Egeberg Aasland added the comment: > I'd prefer writing a PEP and fix all modules once and for all. Berker, I started drafting a PEP. Would you be interested in helping? -- ___ Python tracker ___

[issue43094] sqlite3 signature discrepancies between documentation and implementation

Erlend Egeberg Aasland added the comment: > If we are going to change public sqlite3 APIs in to be positional-only, I'd > prefer writing a PEP and fix all modules once and for all. Right. I assume you mean that such a PEP would contain a set of guidelines for how to handle these dilemmas? It

[issue43094] sqlite3 signature discrepancies between documentation and implementation

Berker Peksag added the comment: The problem is that sqlite3 isn't the only module where there are discrepancies between documentation and implementation. If we are going to change public sqlite3 APIs in to be positional-only, I'd prefer writing a PEP and fix all modules once and for all. -

[issue43094] sqlite3 signature discrepancies between documentation and implementation

Erlend Egeberg Aasland added the comment: sqlite3.Connection.set_progress_handler() docs: set_progress_handler(handler, n) impl: set_progress_handler(progress_handler, n) Apart from that, the rest of sqlite3.Connection seems to be ok. There's an ongoing discussion at python-dev about how to