[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Chris Monsanto added the comment: This issue has been open for 4 years, last update was 2 months ago. Lack of transactional DDL is a big deal for Python programs that use SQLite heavily. We have a patch for Python 3 that applies cleanly and as far as I can tell works fine. I've been using it in testing for months, and I'm about to deploy it in production. What's the next step here? What do we need to do to get something merged? -- nosy: +monsanto ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10740] sqlite3 module breaks transactions and potentially corrupts data
Chris Monsanto added the comment: Unfortunately, I don't have backwards-compatible proposal to fix this. Trying to account for a bit more syntax will help in the short term but not fix the underlying issue. aaugustin -- the patch by torsen made 3 years ago is backwards compatible. It adds a hook that you can use to disable autocommits, but you have to opt-in. I think that is good enough for now. We can worry about how to transition people away from the broken transaction model in the future. Let's treat this as any other backwards compatibility problem in Python. We have a flag, that when enabled, removes the shitty behavior. In a future release, you get a warning for relying on the shitty behavior. In a release after that, we kill the old behavior. Then we deprecate the flag. In other words, it literally doesn't matter what the flag is. torsen's is fine. We just need some way to enable transactional DDL. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10740 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9226] erroneous behavior when creating classes inside a closure
New submission from Chris Monsanto ch...@monsan.to: I have a function whose closure contains a local variable that shadows a global variable (lets call it x). If I create a class as follows: class Test(object): x = x Test.x will contain the value of the global x, not the local x. This ONLY happens when the names are the same, and it only happens in the class body; i.e., class Test(object): y = x and class Test(object): pass; Test.x = x work fine. However, if there is an assignment x = x AND you make other assignments, such as y = x, in the body, the other variables will have the wrong value too. Test case attached. Problem noticed on Python 2.6.2 on Windows and 2.6.5 on Linux. -- files: test.py messages: 110037 nosy: monsanto priority: normal severity: normal status: open title: erroneous behavior when creating classes inside a closure versions: Python 2.6 Added file: http://bugs.python.org/file17950/test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9226 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9226] erroneous behavior when creating classes inside a closure
Chris Monsanto ch...@monsan.to added the comment: A friend confirmed that this was the case on 3.1.2 as well. -- versions: +3rd party -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9226 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9226] erroneous behavior when creating classes inside a closure
Changes by Chris Monsanto ch...@monsan.to: -- versions: +Python 2.6, Python 3.1 -3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9226 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
