##// END OF EJS Templates
Use check_same_thread=False by default for history sqlite db (#13886)...
Use check_same_thread=False by default for history sqlite db (#13886) I had run into the following exception while trying to use IPython in a thread: ``` Traceback (most recent call last): File "/usr/local/lib/python3.11/dist-packages/IPython/core/interactiveshell.py", line 3745, in atexit_operations self._atexit_once() File "/usr/local/lib/python3.11/dist-packages/IPython/core/interactiveshell.py", line 3728, in _atexit_once self.history_manager.end_session() File "/usr/local/lib/python3.11/dist-packages/IPython/core/history.py", line 576, in end_session self.writeout_cache() File "/usr/local/lib/python3.11/dist-packages/decorator.py", line 232, in fun return caller(func, *(extras + args), **kw) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/IPython/core/history.py", line 60, in only_when_enabled return f(self, *a, **kw) ^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/dist-packages/IPython/core/history.py", line 831, in writeout_cache self._writeout_input_cache(conn) File "/usr/local/lib/python3.11/dist-packages/IPython/core/history.py", line 812, in _writeout_input_cache with conn: sqlite3.ProgrammingError: SQLite objects created in a thread can only be used in that same thread. The object was created in thread id 139673788811008 and this is thread id 139673823184704. ``` And discovered that an issue (#680) has been open for it since 2011. Back in [2012](https://github.com/ipython/ipython/issues/680#issuecomment-3444922), it seems like the only reason not to fix it was that the parameter `check_same_thread` was not documented, but now [it is](https://docs.python.org/3.11/library/sqlite3.html#sqlite3.connect), and it has been at least since [3.6](https://docs.python.org/3.6/library/sqlite3.html#sqlite3.connect). Note that according to the docs: > check_same_thread ([bool](https://docs.python.org/3/library/functions.html#bool)) – If True (default), only the creating thread may use the connection. If False, the connection may be shared across multiple threads; if so, write operations should be serialized by the user to avoid data corruption. But I don't think this is an issue here. The operations should be synchronized by the user only *on the same connection object*, and if I'm not mistaken, if two instances of IPython were started in separate threads, they'd each have their own history manager with its own connection. The exception above (and the one in the related issue) is raised from `atexit`, when the main thread is running finalizations registered by other threads. At that point, the operations are serial anyway because they are executed in a single thread.

File last commit:

r20268:5a85bc78
r28320:2da6fb98 merge
Show More
README.md
20 lines | 1.0 KiB | text/x-minidsrc | MarkdownLexer

Documenting What's New

When making a new pull request that either adds a new feature, or makes a
backwards-incompatible change to IPython, please add a new .rst file in this
directory documenting this change as a part of your Pull Request.

This will allow multiple Pull Requests to do the same without conflicting with
one another. Periodically, IPython developers with commit rights will run a
script and populate development.rst
with the contents of this directory, and clean it up.

Files which describe new features can have any name, such as
antigravity-feature.rst, whereas backwards incompatible changes must have
have a filename starting with incompat-, such as
incompat-switching-to-perl.rst. Our "What's new" files always have two
sections, and this prefix scheme will make sure that the backwards incompatible
changes get routed to their proper section.

To merge these files into :file:whatsnew/development.rst, run the script :file:tools/update_whatsnew.py.