[issue1734164] sqlite3 causes memory read error

Gerhard Häring added the comment: This was already reported upstream at http://initd.org/tracker/pysqlite/ticket/205 It's a bug in the SQLite version of the DLL is shipped with Python 2.5 on Windows. Updating the DLL to a newer version would help. In the meantime, users can just downloa

[issue1734164] sqlite3 causes memory read error

Changes by Gerhard Häring: -- type: -> crash versions: +Python 2.5 _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1734164> _ ___ Python-bu

[issue1597404] sqlite timestamp converter bug (floating point)

Gerhard Häring added the comment: This has long been fixed in revision 53420. So it will be in Python 2.6 and 3.0. -- resolution: -> fixed status: open -> closed type: -> behavior _ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue1706863] Failed to build Python 2.5.1 with sqlite3

Gerhard Häring added the comment: This is apparently a problem in setup.py. There seems to be a code path where an object should be a string, but is None instead. I'll have to review the relevant parts of setup.py. -- nosy: +ghaering type: -> compi

[issue1733085] sqlite3 module trigger problem

Gerhard Häring added the comment: We'll make sure there's an updated SQLite DLL in Python 2.6 and Python 3.0. It's not worth the effort for 2.5.2. There's always the workaround of users installing an updated DLL themselves. -- resolution: -> later

[issue1734164] sqlite3 causes memory read error

Gerhard Häring added the comment: Ok, I'll modify the 2.5 maintenance line with this patch: http://initd.org/tracker/pysqlite/changeset/426 _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.or

[issue1734164] sqlite3 causes memory read error

Gerhard Häring added the comment: Fixed in revision 59184. -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.o

[issue6683] smtplib authentication - try all mechanisms

Gerhard Häring added the comment: Wow! That's great! -- ___ Python tracker <http://bugs.python.org/issue6683> ___ ___ Python-bugs-list mailing list Unsubsc

[issue9750] sqlite3 iterdump fails on column with reserved name

Changes by Gerhard Häring : -- assignee: -> ghaering ___ Python tracker <http://bugs.python.org/issue9750> ___ ___ Python-bugs-list mailing list Unsubscri

[issue9924] sqlite3 SELECT does not BEGIN a transaction, but should according to spec

Gerhard Häring added the comment: Yes Mike. Avoiding unnecessary locks was exactly the reason for this behaviour. I agree that for serializable transactions I'd need to make some changes. -- ___ Python tracker <http://bugs.python.org/i

[issue10020] docs for sqlite3 describe functions not available without recompiling

Gerhard Häring added the comment: Without SQLITE_OMIT_LOAD_EXTENSION, builds will break on Mac OS X 10.5 and 10.6 and maybe other platforms. -- ___ Python tracker <http://bugs.python.org/issue10

[issue10020] docs for sqlite3 describe functions not available without recompiling

Gerhard Häring added the comment: Fixed in r85208 by adding a note to the docs. -- resolution: -> fixed status: open -> pending ___ Python tracker <http://bugs.python.org/i

[issue2127] sqlite3 docs should mention utf8 requirement

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Can we close this now? Did you try out a Python2.6 or Python 3.0 beta? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3783] dbm.sqlite proof of concept

Gerhard Häring <[EMAIL PROTECTED]> added the comment: I like Skip's version better, because it's closer to the dbm "specification" instead of trying to mimic bsddb (first, last, etc.). I'd like to keep such things out. I've made a few changes to the sandbox

[issue3783] dbm.sqlite proof of concept

Gerhard Häring <[EMAIL PROTECTED]> added the comment: One question about Josiah's _check_value(). SQLite is less crippled than other simplistic databases and also supports integers, reals and blobs in addition to strings. Shouldn't we make this accessible to users? Or is co

[issue3783] dbm.sqlite proof of concept

Gerhard Häring <[EMAIL PROTECTED]> added the comment: > I'd like to guarantee that zip(db.keys(), db.values() == db.items(). Ok. If that isn't guaranteed elsewhere just drop it here? FWIW that will also work without the ORDER BY, because you're getting the row

[issue3783] dbm.sqlite proof of concept

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Skip Montanaro wrote: > Skip Montanaro <[EMAIL PROTECTED]> added the comment: > > Gerhard> FWIW that will also work without the ORDER BY, because you're > Gerhard> getting the rows back in the same ORD

[issue3103] sqlite defines a few global symbols.

Gerhard Häring <[EMAIL PROTECTED]> added the comment: I've fixed that in the externally maintained pysqlite. I suppose it's too late to bring this into 2.6 or 3.0, right? ___ Python tracker <[EMAIL PROTECTED]> <http://

[issue3846] sqlite3 module: Improved concurrency

New submission from Gerhard Häring <[EMAIL PROTECTED]>: I'd really like this change to get into Python 2.6. It's pretty trivial (just releases the GIL when compiling SQLite statements), but improves concurrency for SQLite. This means less "database is locked" er

[issue3846] sqlite3 module: Improved concurrency

Changes by Gerhard Häring <[EMAIL PROTECTED]>: -- keywords: +needs review -patch priority: -> high ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue3847] Begging for review

New submission from Gerhard Häring <[EMAIL PROTECTED]>: Could one of you please give me a review for the trivial patch at http://bugs.python.org/issue3846 It releases the GIL around sqlite3_prepare calls to improve concurrency. Many thanks -- Gerhard -- files: unnamed me

[issue3103] sqlite defines a few global symbols.

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Patch to Python 2.6 with Misc/NEWS entry if we want to close this now. Added file: http://bugs.python.org/file11475/patch_sqlite3_global_symbols.dif ___ Python tracker <[EMAIL PROTECTE

[issue3846] sqlite3 module: Improved concurrency

Gerhard Häring <[EMAIL PROTECTED]> added the comment: 1. SQLite calling back Good that you mention it. During sqlite3_prepare, SQLite can call the authorizer_callback. Fortunately, it already acquires/releases the GIL appropriately already. 2. Other thread closing connection, etc. Conne

[issue3847] Begging for review

Gerhard Häring <[EMAIL PROTECTED]> added the comment: I accidentally created this issue -- resolution: -> invalid status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs

[issue3846] sqlite3 module: Improved concurrency

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Interesting. I was smart enough to not document check_same_thread in the sqlite3 incarnation of the module. This has nothing to do with releasing/aquiring the GIL around sqlite3_prepare, though. Adding the macros was just an ove

[issue3846] sqlite3 module: Improved concurrency

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Just to be explicit: check_same_thread is unsupported and while it's undocumented in sqlite3, the old pysqlite docs say that when you use it, you have to make sure the connections/cursors are protected otherwise (via your own mut

[issue3846] sqlite3 module: Improved concurrency

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Thanks, Martin. Commited as r66414. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3846> ___

[issue3103] sqlite defines a few global symbols.

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Committed in r66412. -- status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue3853] Windows SQLite DLL should be built with multithreading enabled

New submission from Gerhard Häring <[EMAIL PROTECTED]>: According to http://www.sqlite.org/faq.html#q6 SQLite should be built with SQLITE_THREADSAFE defined when the library is used in a multithreaded context. This doesn't mean that the connection objects can then be shared betw

[issue3854] Document sqlite3 vs. threads

New submission from Gerhard Häring <[EMAIL PROTECTED]>: In Issue3846, Martin proposed """"[...] I encourage you to review the entire issue, though, and document somewhere what promises are made under what conditions. Then a later review can validate that th

[issue3846] sqlite3 module: Improved concurrency

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Issue3854 was created for documenting sqlite3 vs. threads. -- status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in switch

Gerhard Häring <[EMAIL PROTECTED]> added the comment: I'll look into this. -- assignee: -> ghaering nosy: +ghaering ___ Python tracker <[EMAIL PROTECTED]> <http://bu

[issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in switch

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Damn. I uploaded a patch to this issue a few days ago for review. Apparently, it didn't work?! I'll recreate it again. ___ Python tracker <[EMAIL PROTECTED]> <http://

[issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in switch

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Attached patch corrects the issue. Could you please review it? -- status: open -> pending Added file: http://bugs.python.org/file11541/py3_sqlite3_str_subclass.dif ___ Python tracke

[issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in switch

Changes by Gerhard Häring <[EMAIL PROTECTED]>: -- keywords: +easy, needs review, patch type: -> behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in switch

Changes by Gerhard Häring <[EMAIL PROTECTED]>: -- status: pending -> open ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3659> ___ __

[issue3659] sqlite: enumeration value 'TYPE_STRING' not handled in switch

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Thanks a lot, Benjamin! Committed revision 66550. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs

[issue4068] Backport fix for issue 3312

New submission from Gerhard Häring <[EMAIL PROTECTED]>: This is a backport of Georg Brandl's fix for issue #3312. -- assignee: ghaering files: 253_backport_fix_issue3312.diff keywords: patch, patch messages: 74454 nosy: ghaering priority: normal severity: normal status:

[issue4068] Backport fix for issue 3312

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Thanks, committed in revision 66843. -- status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue7723] sqlite only accept buffer() for BLOB objects (input/output)

Gerhard Häring added the comment: As far as I can see the docs for Python 3.x need to be adjusted. In particular http://docs.python.org/3.1/library/sqlite3.html#sqlite-and-python-types buffer should then there probably be replaced by memoryview. As far as I can see, the Python 3 definition

[issue7670] _sqlite3: Block *all* operations on a closed Connection object

Gerhard Häring added the comment: Applied in trunk. Thanks! -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue7478] _sqlite3 doesn't catch PyDict_SetItem error

Gerhard Häring added the comment: Fixed in trunk now. Thanks! -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue7670] _sqlite3: Block *all* operations on a closed Connection object

Gerhard Häring added the comment: Now also fixed in 2.6 and 3.1 maintenance branches. -- ___ Python tracker <http://bugs.python.org/issue7670> ___ ___ Python-bug

[issue7670] _sqlite3: Block *all* operations on a closed Connection object

Gerhard Häring added the comment: As requested per Barry, marking this as release blocker for 2.6. -- keywords: +26backport priority: -> release blocker stage: patch review -> commit review status: closed -> open ___ Python track

[issue8145] Documentation about sqlite3 isolation_level

Changes by Gerhard Häring : -- nosy: +ghaering ___ Python tracker <http://bugs.python.org/issue8145> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue8196] sqlit3.paramstyle reported as 'qmark'

Gerhard Häring added the comment: Thanks for bringing this up. By changing this we would maybe be a little bit closer to PEP 0249. I don't get why the PEP author thinks that 'qmark' is less clear than 'numeric', though. I think they're equally clear. The rea

[issue8196] sqlit3.paramstyle reported as 'qmark'

Gerhard Häring added the comment: I said qmark vs numeric. I. e. vs: execute("UPDATE authors set name = :1, email = :2, comment = :3 WHERE id = :4", (form.name, form.email, form.text, form.id)) The sqlite3 module will always support both paramstyles qmark and named, simply becau

[issue5872] New C API for declaring Python types

Changes by Gerhard Häring : -- nosy: +ghaering ___ Python tracker <http://bugs.python.org/issue5872> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue7723] sqlite only accept buffer() for BLOB objects (input/output)

Gerhard Häring added the comment: I see that the status of this issue keeps changing. Now does anything in the sqlite3 module or the docs need to be changed? Or what's left to close this? -- ___ Python tracker <http://bugs.python.org/i

[issue2139] sqlite3 module needs upgrading

Gerhard Häring added the comment: I don't think pysqlite 2.3.2 is very buggy. Otherwise a lot more bug reports about the pysqlite module would have arrived here. About backporting fixes to 2.5.3, I'd have to look which ones are isolated and I could then backport them. As for SQLite,

[issue2157] sqlite numeric type conversion problems

Gerhard Häring added the comment: The same question came up in the external pysqlite project once. My answer is the same here: this won't be fixed because of backwards compatibility reasons. The current behaviour is well documented. I acknowledge that it would be nice to be able t

[issue1546263] Segfaults with concurrent sqlite db access and schema change

Gerhard Häring added the comment: See http://initd.org/tracker/pysqlite/ticket/170 and http://initd.org/tracker/pysqlite/changeset/301 _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/iss

[issue2127] sqlite3 docs should mention utf8 requirement

Changes by Gerhard Häring: -- nosy: +ghaering __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2127> __ ___ Python-bugs-list mailing list Unsubs

[issue2127] sqlite3 docs should mention utf8 requirement

Gerhard Häring added the comment: I'll assign this one to me. The "sqlite3" module cannot be just "refreshed" with the externally maintained pysqlite, I'll have to do merging anyway. Don't worry here ;-) -- assignee: -> ghaering keywords: +e

[issue2152] make sqlite.Row hashable correctly

Changes by Gerhard Häring: -- assignee: -> ghaering nosy: +ghaering priority: -> normal __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2152> __ _

[issue2157] sqlite numeric type conversion problems

Gerhard Häring added the comment: It's mentioned here: http://docs.python.org/lib/sqlite3-Module-Contents.html __ Tracker <[EMAIL PROTECTED]> <http://bugs.python

[issue2157] sqlite numeric type conversion problems

Gerhard Häring added the comment: Yes, I acknowledge the backwards incompatibility is rather a one in a billion case than a one in a million case. I'll reopen this one and integrate your patch or something similar for Python 2.6 and 3.0. -- resolution: wont fix -> status

[issue2127] sqlite3 docs should mention utf8 requirement

Gerhard Häring added the comment: I didn't try the patch out, yet. But I'd instead try to just open u":memory" instead. Also, in Lib/test/test_sqlite.py the sqlite tests are started. They are of course run as part of the Python test suite. __

[issue2215] test_sqlite fails in 2.6a1 on MacOS X

Gerhard Häring added the comment: Revision 61141 made the test work with old SQLite versions. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2215> __ ___ Pyth

[issue2215] test_sqlite fails in 2.6a1 on MacOS X

Changes by Gerhard Häring: __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2215> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mai

[issue2215] test_sqlite fails in 2.6a1 on MacOS X

Gerhard Häring added the comment: r61174 made the tests work with old SQLite versions. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2215> __ ___ Python-bugs-

[issue2500] Sync _sqlite module code

Gerhard Häring <[EMAIL PROTECTED]> added the comment: I know. I'll do it this weekend. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2500> __ ___ P

[issue1546263] Segfaults with concurrent sqlite db access and schema change

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Long fixed in 2.6 and 3.0 branches. Don't think it's worth fixing it in 2.5. -- resolution: -> wont fix status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http

[issue1625205] sqlite3 documentation omits: close(), commit(), autocommit

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Fixed in r62026. Thanks for bringing this up. -- resolution: -> fixed status: open -> closed _ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue2500] Sync _sqlite module code

Gerhard Häring <[EMAIL PROTECTED]> added the comment: done. the py3k branch is now up-to-date wrt to the sqlite3 module. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2152] make sqlite.Row hashable correctly

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Thomas, could you do me a favour and create a patch for Python 3.0, too? It seems that only tp_richcompare is supported there. __ Tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue2215] test_sqlite fails in 2.6a1 on MacOS X

Changes by Gerhard Häring <[EMAIL PROTECTED]>: -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2215> __ __

[issue2441] Mac build_install.py script fetches unavailable SQLite version

Changes by Gerhard Häring <[EMAIL PROTECTED]>: -- assignee: -> ghaering nosy: +ghaering __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2441> __ ___

[issue2176] Undocumented lastrowid attribute i sqlite3 cursor class

Changes by Gerhard Häring <[EMAIL PROTECTED]>: -- assignee: georg.brandl -> ghaering nosy: +ghaering __ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue2176] Undocumented lastrowid attribute i sqlite3 cursor class

Gerhard Häring <[EMAIL PROTECTED]> added the comment: The lastrowid attribute is now documented in r62044. Thanks for bringing this up. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2152] make sqlite.Row hashable correctly

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Thanks a lot! I will review and apply this after the next releases. Don't want to rush things in now that the next alphas are so close. Btw. I don't find forward-porting to py3k particularly easy. The diffs between the 2.6 ve

[issue2540] If HAVE_LONG_LONG is not defined, longval will not be initialized (_sqlite)

Gerhard Häring <[EMAIL PROTECTED]> added the comment: My problem is that I can't really test (better than #undefining HAVE_LONG_LONG) this, because I have no platform to test on that doesn't have long longs. I'm not even sure SQLite *really* works when there is no 64-bit

[issue2515] Segfault while operating on closed sqlite3 cursor.

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Thanks for reporting this. It's fixed in r62183 in the 2.5 maintenance branch. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http:/

[issue2277] MozillaCookieJar does not support Firefox3 cookie files

Changes by Gerhard Häring <[EMAIL PROTECTED]>: -- nosy: +ghaering __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2277> __ ___ Python-bugs

[issue2441] Mac build_install.py script fetches unavailable SQLite version

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Glyph, do you know somebody with a Mac who could verify this patch? Perhaps you have a Mac yourself? :-) I'd suggest to update the patch to the latest SQLite version then while at it (3.5.8 currently). -- assignee: ghaeri

[issue2540] If HAVE_LONG_LONG is not defined, longval will not be initialized (_sqlite)

Gerhard Häring <[EMAIL PROTECTED]> added the comment: SQLite requires 64-bit integers in order to build. So the whole HAVE_LONG_LONG #ifdefing was useless. I've removed it in r62700. -- resolution: -> rejected status: open -> closed _

[issue2152] make sqlite.Row hashable correctly

Gerhard Häring <[EMAIL PROTECTED]> added the comment: I applied your second patch in r62701. Thanks again! -- resolution: -> accepted __ Tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue2157] sqlite numeric type conversion problems

Gerhard Häring <[EMAIL PROTECTED]> added the comment: Implemented in r62702. -- resolution: -> accepted status: open -> closed __ Tracker <[EMAIL PROTECTED]> <http://bugs

[issue2127] sqlite3 docs should mention utf8 requirement

Gerhard Häring <[EMAIL PROTECTED]> added the comment: The implementation in SVN should in the meatntime behave like you expect now. Look for database_utf8 = PyUnicode_AsUTF8String(database); in connection.c to see the implementation. __ Tracker <[EMAIL

[issue5134] Compiler warnings in sqlite module

Gerhard Häring added the comment: This is a known issue with SQLite. It's not as bad as it looks at first sight, though. http://www.sqlite.org/faq.html#q17 """ (17) I get hundreds of compiler warnings when I compile SQLite. Isn't this a problem? Doesn't it indica

[issue5134] Compiler warnings in sqlite module

Gerhard Häring added the comment: I propose to either close this as wontfix. I don't know the switches for the Microsoft compiler to disable the warnings myself. ___ Python tracker <http://bugs.python.org/i

[issue15460] SQLite cursor.description is not DB-API compatible

Gerhard Häring added the comment: SQLite's columns aren't typed, only SQLite values are. So it's entirely possible for the same column to have different types, like the NULL type, the INTEGER type and the TEXT type. It's thus impossible to give meaningful type information

[issue6683] smtplib authentication - try all mechanisms

Changes by Gerhard Häring : -- assignee: -> ghaering nosy: +ghaering ___ Python tracker <http://bugs.python.org/issue6683> ___ ___ Python-bugs-list mai

[issue2441] Mac build_install.py script fetches unavailable SQLite version

Gerhard Häring added the comment: This has long been fixed. Even for 2.6maint the SQLite version currently being fetched is 3.6.11. -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python.org/

[issue7394] sqlite3: some OperationalError exceptions should be ProgrammingError (PEP 249)

Gerhard Häring added the comment: The error code SQLITE_ERROR from SQLite is used for "runtime errors". These can either be caused by the programmer (table does not exist, SQL contains errors) or they can be other problems like constraint violations etc. To differentiate these we wou

[issue7478] _sqlite3 doesn't catch PyDict_SetItem error

Gerhard Häring added the comment: Thanks! I've integrated this into pysqlite (http://code.google.com/p/pysqlite/source/detail?r=6455981b3283b26c147d949a9031a0d74ea7ffe8) and will soon push updates to the version in Python core. In my opinion this changes is not critical enough to wa

[issue7572] Strabge issue : cursor.commit() with sqlite

Gerhard Häring added the comment: Please change your test case so that it works with an in-memory database ":memory:". Then you'll also need to include a schema creation command "create table", which is missing here. Please also state which behaviour you see and whic

[issue7572] Strange issue : cursor.commit() with sqlite

Changes by Gerhard Häring : -- title: Strabge issue : cursor.commit() with sqlite -> Strange issue : cursor.commit() with sqlite ___ Python tracker <http://bugs.python.org/iss

[issue7572] Strange issue : cursor.commit() with sqlite

Gerhard Häring added the comment: You confuse two things here: cursors and connections. Indeed closing a connection without calling commit() on it will do an implicit rollback, i. e. any changes on the database will not be persisted. Closing cursors, however does nothing except invalidating

[issue5033] setup.py crashes if sqlite version contains 'beta'

Changes by Gerhard Häring : -- assignee: -> ghaering nosy: +ghaering priority: -> low ___ Python tracker <http://bugs.python.org/issue5033> ___ ___ Pyth

[issue6057] sqlite3 error classes should be documented

Gerhard Häring added the comment: At the very start of the module's documentation it reads: """ pysqlite was written by Gerhard Häring and provides a SQL interface compliant with the DB-API 2.0 specification described by PEP 249. """ Where "PE

[issue9303] Migrate sqlite3 module to _v2 API to enhance performance

Gerhard Häring added the comment: Yes, the sqlite module uses the old API, and is written to work with older SQLite releases and their respective bugs as well. Using the new API will mean requiring newer SQLite releases. If we do this, then this is the chance to remove all the obscure

[issue588756] python should obey the FHS

Changes by Gerhard Häring : -- nosy: -ghaering ___ Python tracker <http://bugs.python.org/issue588756> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9510] sqlite3.Warning isnt a subclass of exceptions.Warning

Gerhard Häring added the comment: PEP 0249 says that the module's Warning class must be a subclass of StandardError. So I reject your proposed change. There are only two cases where pysqlite raises Warning, and these could be changed to ProgrammerError anyway. -- ass

[issue6683] smtplib authentication - try all mechanisms

Gerhard Häring added the comment: Fixed in r83742. I implemented this without a test case, because if we wait for a test case for this, we can wait forever (would need a SMTP server implementation in Python for the various auth methods

[issue8196] sqlit3.paramstyle reported as 'qmark'

Gerhard Häring added the comment: There is too little value changing the paramstyle attribute. I think the documentation clearly states that both parameter binding methods are supported. -- resolution: -> rejected status: open -> closed ___

[issue4032] distutils cannot recognize ".dll.a" as library on cygwin

Changes by Gerhard Häring : -- nosy: -ghaering ___ Python tracker <http://bugs.python.org/issue4032> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue3854] Document sqlite3 vs. threads

Gerhard Häring added the comment: Fixed in r83747. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue3854> ___ __

[issue22956] Improved support for prepared SQL statements

Gerhard Häring added the comment: The low-hanging fruit of executemany() reusing the prepared statement is of course taken. Also, there is a statement cache that is being used transparently. I am against exposing the statement directly via the API. -- assignee: -> ghaering n

[issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection

Gerhard Häring added the comment: I have now committed a fix in the pysqlite project at github. https://github.com/ghaering/pysqlite/commit/f67fa9c898a4713850e16934046f0fe2cba8c44c I'll eventually merge it into the Python tree. -- assignee: -> ghaering nosy: +

  1   2   >