On Tue, 1 Nov 2022 at 14:37, Marc-Andre Lemburg <m...@egenix.com> wrote:
> […] Instead, I believe we should document what many modules already > implement, which is the read/write .autocommit attribute. As for semantics, > we should probably go with option 3 and only mention that many modules will > actually already implement option 2. > +1 Regarding the problem with having attribute write access result in possible > I/O, I think we should at the same time deprecate the write nature of the > .autocommit attribute and announce that it'll be replaced with a newmethod, > e.g. .setautocommit() (the DB-API has traditionally not added underscores > to the names, except for the optional TPC API group), for DB-API 3.0. > For the upcoming autocommit attribute of the stdlib sqlite3 module, I wonder if we should stick with these conventions right from the start. That is, autocommit can either be set from the connection constructor (using the new autocommit property), or using a setautocommit() method. The autocommit attribute will be read-only. Related to this, I'd also suggest adding a new keyword parameter to the > connection constructor (autocommit), which defaults to False and can be > used to create autocommit connections right from the start. > +1 Erlend
_______________________________________________ DB-SIG maillist - DB-SIG@python.org https://mail.python.org/mailman/listinfo/db-sig
