[issue36466] Adding a way to strip annotations from compiled bytecode
New submission from cary : Similar to how `-OO` currently strips docstrings from compiled bytecode, it would be nice if there were a way to strip annotations as well to further compact the bytecode. Attached is my initial attempt. From some simple manual testing, Python with this patch applied will generate the same bytecode (verified with `marshal` and `dis`) for two files with the same logic, but with annotations manually removed from one of them. This will probably need some new flag/optimization level rather than relying on `-OO` (as it would be a breaking change). Open to initial reviews of the patch and idea in general, and suggestions on how to best thread the option through to the module. -- components: Interpreter Core files: strip_annotations.patch keywords: patch messages: 339091 nosy: cary priority: normal severity: normal status: open title: Adding a way to strip annotations from compiled bytecode type: enhancement Added file: https://bugs.python.org/file48237/strip_annotations.patch ___ Python tracker <https://bugs.python.org/issue36466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36466] Adding a way to strip annotations from compiled bytecode
cary added the comment: Thanks for the feedback! I wasn't aware that modules depended on this during runtime. Abandoning this :) -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33376] [pysqlite] Duplicate rows can be returned after rolling back a transaction
New submission from cary :
# Description
Rolling back a transaction causes all statements associated with that
transaction to be reset, which allows the statements to be used again from the
pysqlite statement cache. This can interact with various methods on `Cursor`
objects to cause these statements to be reset again, possibly when they are in
use by a different cursor.
This appears to be very similar to issue10513 and issue23129.
# Impact
Duplicate rows will be returned. Exceptions can be raised.
# Repro steps
- Cursor *A* executes query *X*
- Rollback occurs
- Cursor *B* executes query *X*
- Any of the following (and there might be other cases too):
- Cursor *A* is closed
- Cursor *A* is deallocated
- Cursor *A* executes any other query.
- Result: Cursor *B* returns duplicate rows.
- Furthermore: Executing query *X* again afterwards raises
`sqlite3.InterfaceError`
# Possible solutions
- Similar to the solution for issue10513 and issue23129, we could remove
`pysqlite_do_all_statements(self, ACTION_RESET, 1)` from
`pysqlite_connection_rollback`. This fixes the given issue, but I'm not sure
what the implications are for the rest of the system.
- Do not reset `self->statement` in `Cursor` if `self->reset`. This is the
fix we've adopted for now (through a local patch to our Python), but it's worth
noting that this is rather brittle, and only works because
`pysqlite_do_all_statements` is always called with `reset_cursors = 1`, and
`self->reset` is not modified in too many places.
# Example
```
import sqlite3 as sqlite
if __name__ == '__main__':
conn = sqlite.connect(":memory:")
conn.executescript("""
CREATE TABLE t(c);
INSERT INTO t VALUES(0);
INSERT INTO t VALUES(1);
INSERT INTO t VALUES(2);
""")
curs = conn.cursor()
curs.execute("BEGIN TRANSACTION")
curs.execute("SELECT c FROM t WHERE ?", (1,))
conn.rollback()
# Reusing the same statement from the statement cache, which has been
# reset by the rollback above.
gen = conn.execute("SELECT c FROM t WHERE ?", (1,))
# Any of the following will cause a spurious reset of the statement.
curs.close()
# curs.execute("SELECT 1")
# del curs
# Expected output: [(0,), (1,), (2,)]
# Observed output: [(0,), (0,), (1,), (2,)]
print(list(gen))
# Raises `sqlite3.InterfaceError: Error binding parameter 0 - probably
unsupported type.`
conn.execute("SELECT c FROM t WHERE ?", (1,))
```
--
components: Extension Modules
messages: 315862
nosy: cary
priority: normal
severity: normal
status: open
title: [pysqlite] Duplicate rows can be returned after rolling back a
transaction
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue33376>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33376] [pysqlite] Duplicate rows can be returned after rolling back a transaction
Change by cary : -- keywords: +patch pull_requests: +9564 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33376> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7833] Bdist_wininst installers fail to load extensions built with Issue4120 patch
John Cary added the comment: Just to follow up. My case is an application that is almost all statically linked, but it loads in the python library, and at runtime it needs to load the tables module, and as distributed by Python, I get the load-time error on Windows. Using Christoph Gohlke's exe's works great for me, but I cannot redistribute due to the linking in of szip for tables and MKL for numpy. So I build my own version of tables without szip and numpy without MKL, but that failed until I applied Christoph's patch on Python. (I also have to patch tables' setup.py not to include szip.dll and zlib1.dll in dll_files.) So the result is that with Christoph's patch, all is working for me. I hope it (or something similar) makes it into 2.7. John Cary -- nosy: +John.Cary ___ Python tracker <http://bugs.python.org/issue7833> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5961] Missing labelside option for Tix option menu (fix included)
Cary R. added the comment: That is the manual I am referencing and the last time I looked it was the most recent. I'm not to familiar with the Python port of Tix, but I am using the command, label, state, and variable options and they already work fine. I could try the other options if that would help. I needed the labelside functionality so I hacked Tix.py to get it to work. I mimicked the code from other objects that have a labelside option. My assumption was that some base class knew how to handle many of the standard options, but did not know about labelside. It is possible that there is a better way to handle this (add it to the same place the others are implemented), but that would have required understanding the class hierarchy and much more work. At the time I just needed to get it to work and what I proposed does work and is consistent with other objects. Since I was not using the other options I did not check them. Let me know if there is anything else I can do to help. -- ___ Python tracker <http://bugs.python.org/issue5961> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5961] Missing labelside option for Tix option menu (fix included)
New submission from Cary R. : The Tix Optionmenu is documented to support a labelside option that is used to specify where the label should be relative to the selection. I have verified that adding 'labelside' to the static_options when calling the base constructor (TixWidget.__init__) located in Tix.py line 1185 (for both 2.5.4 and 2.6.2) fixes the problem. TixWidget.__init__(self, ... ,['labelside', 'options'], ... ) I am currently using 2.5.4, but a fix only for the 2.6 branch is acceptable for all but my personal machine (which I can patch by hand). I am not very familiar with how all this works, so if there is something I can do from my code to add this option that would be nice to know. -- components: Tkinter messages: 87388 nosy: caryr severity: normal status: open title: Missing labelside option for Tix option menu (fix included) type: feature request versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5961> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5961] Missing labelside option for Tix option menu (fix included)
Changes by Cary R. : -- versions: +Python 2.5 ___ Python tracker <http://bugs.python.org/issue5961> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
