gh-107938: Synchonise the signature of of sqlite3.connect and sqlite3.Connection.__init__#107939
Conversation
…qlite3.Connection.__init__
|
Suggesting to backport this, in order to easier backport docstring updates. |
|
cc. @serhiy-storchaka, if you want to look this over; it is a trivial change |
serhiy-storchaka
left a comment
There was a problem hiding this comment.
This is an interesting trick, but in future they can divergent.
Connection.__init__ and __init__ in its subclasses currently require the factory parameter to be supported, even if it is ignored. This is both a wart and an artifact of implementation. It may be removed in the future, and from then on the connect and Connection.__init__ signatures will be different.
It is a long way, and I think that it can only happen in distant future, but you should be aware of consequences.
|
Yes, that is true, but as you say, it is a long way into the future. For now, it makes it simpler for us to do stuff like deprecating positional use of parameters. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
…qlite3.Connection.__init__ (pythonGH-107939) (cherry picked from commit 6fbaba5) Co-authored-by: Erlend E. Aasland <erlend@python.org>
This comment was marked as outdated.
This comment was marked as outdated.
|
BTW, after making all optional arguments keyword-only, why not implement def connect(database, *, factory=Connection, **kwargs):
return factory(database, **kwargs) |
That is a very good idea. BTW, I've toyed the idea of with turning |
This comment was marked as outdated.
This comment was marked as outdated.
…t and sqlite3.Connection.__init__ (python#107939) (cherry picked from commit 6fbaba5)
|
Ah, of course, we cannot backport this because the clone |
sqlite3.connect? andsqlite3.Connection.__init__` #107938