[issue46936] Fix grammar_grapher with the new forced directive
New submission from Luca :
The grammar_grapher.py utility has not been updated after the introduction of
the new "forced" directive ('&&') in the grammar (see
https://github.com/python/cpython/pull/24292) and fails to visualize the
current Python grammar.
--
components: Parser
messages: 414608
nosy: lucach, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Fix grammar_grapher with the new forced directive
___
Python tracker
<https://bugs.python.org/issue46936>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46936] Fix grammar_grapher with the new forced directive
Change by Luca : -- keywords: +patch pull_requests: +29823 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31704 ___ Python tracker <https://bugs.python.org/issue46936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46936] Fix grammar_grapher with the new forced directive
Change by Luca : -- pull_requests: +29842 pull_request: https://github.com/python/cpython/pull/31719 ___ Python tracker <https://bugs.python.org/issue46936> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45463] Documentation inconsistency on the number of identifiers allowed in global stmt
New submission from Luca : The global statement allows specifying a list of identifiers, as correctly reported in the "Simple statements" chapter: https://docs.python.org/3/reference/simple_stmts.html#the-global-statement. Inconsistently, however, the "Execution model" chapter describes the global statement as if it only allowed one single name. This can be addressed by pluralizing the word "name" in the appropriate places in the "Execution model" chapter. -- assignee: docs@python components: Documentation messages: 403864 nosy: docs@python, lucach priority: normal pull_requests: 27227 severity: normal status: open title: Documentation inconsistency on the number of identifiers allowed in global stmt ___ Python tracker <https://bugs.python.org/issue45463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45968] Windows installer should add also "%USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts" folder to the PATH environment variable
New submission from Luca : This issue is related to https://bugs.python.org/issue3561 When installing Python under Windows, if the "Add Python 3.x to PATH" option is flagged, the following two folders are added to the PATH environment variable: %USERPROFILE%\AppData\Local\Programs\Python\Python3x\ %USERPROFILE%\AppData\Local\Programs\Python\Python3x\Scripts\ However also the following folder should be added, which is where scripts reside when packages are installed with "pip install --user": %USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts\ -- components: Installation, Windows messages: 407550 nosy: lucatrv, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows installer should add also "%USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts" folder to the PATH environment variable type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45969] When uninstalling Python under Windows the "Scripts" folders should be removed from the PATH environment variable
New submission from Luca : This issue is related to: https://bugs.python.org/issue3561 and: https://bugs.python.org/issue45968 When installing Python under Windows, if the "Add Python 3.x to PATH" option is flagged, the following two folders are added to the PATH environment variable: %USERPROFILE%\AppData\Local\Programs\Python\Python3x\ %USERPROFILE%\AppData\Local\Programs\Python\Python3x\Scripts\ However when uninstalling Pyhton only the former folder is removed from the PATH environment variable, and not the latter one. Moreover if also the following folder will be added to the PATH environment variable in future (see issue #45968): %USERPROFILE%\AppData\Roaming\Python\Python3x\Scripts\ then the same would apply to it. -- components: Installation, Windows messages: 407551 nosy: lucatrv, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: When uninstalling Python under Windows the "Scripts" folders should be removed from the PATH environment variable type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue45969> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39658] Include user scripts folder to PATH on Windows
New submission from Luca : When installing Python on Windows, and selecting the option “Add Python to PATH”, the following folders are added to the "PATH" environment variable: - C:\Users\[username]\AppData\Local\Programs\Python\Python38\Scripts\ - C:\Users\[username]\AppData\Local\Programs\Python\Python38\ However also the following folder should be added, _before_ the other two: - C:\Users\[username]\AppData\Roaming\Python\Python38\Scripts\ This is needed to correctly expose scripts of packages installed with `pip install --user` (`pip` emits a warning when installing a script with `--user` flag if that folder is not in "PATH"). -- components: Installation messages: 362108 nosy: lucatrv priority: normal severity: normal status: open title: Include user scripts folder to PATH on Windows ___ Python tracker <https://bugs.python.org/issue39658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39809] argparse: add max_text_width parameter to ArgumentParser
New submission from Luca : It is often desirable to limit the help text width, for instance to 78 or 88 columns, regardless of the actual size of the terminal window. Currently you can achieve this in rather cumbersome ways, for instance by setting "os.environ['COLUMNS'] = '80'" (but this requires the "os" module, which may not be needed otherwise by your module, and may lead to other undesired effects), or by writing a custom formatting class. IMHO there should be a simpler option for such a basic task. I propose to add a max_text_width parameter to ArgumentParser. This would require only minor code changes to argparse (see attached patch), should I open a pull request on GitHub? -- components: Library (Lib) files: argparse_max_text_width.patch keywords: patch messages: 363053 nosy: lucatrv priority: normal severity: normal status: open title: argparse: add max_text_width parameter to ArgumentParser type: enhancement versions: Python 3.9 Added file: https://bugs.python.org/file48939/argparse_max_text_width.patch ___ Python tracker <https://bugs.python.org/issue39809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39809] argparse: add max_text_width parameter to ArgumentParser
Luca added the comment: That lambda function would not give the same result, as it would constrain the text width to a fixed value, while my proposal would just set a maximum limit (if the terminal is narrower, the actual text width would be reduced). With the current implementation all possible solutions are in my opinion overkilling for such a basic task. Maybe it is not a direct consequence of this, but as a matter of fact most Python scripts using `argparse` that I know (including `pip`) do not control the text width, which IMHO is not a good practice. -- ___ Python tracker <https://bugs.python.org/issue39809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39809] argparse: add max_text_width parameter to ArgumentParser
Luca added the comment: OK, I will do this for my package, but I do not believe many others will do the same without a `max_text_width` parameter (too much care is needed for this to work correctly), and as a result most packages using `argparse` will continue to not properly handle text width. -- ___ Python tracker <https://bugs.python.org/issue39809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39809] argparse: add max_text_width parameter to ArgumentParser
Luca added the comment: For the benefit of other developers willing to control text width with `argparse`, using the lambda function let `mypy` fail with the following error: 541: error: Argument "formatter_class" to "ArgumentParser" has incompatible type "Callable[[Any], RawDescriptionHelpFormatter]"; expected "Type[HelpFormatter]" So I am reverting back to the following custom formatting class: class RawDescriptionHelpFormatterMaxTextWidth80(argparse.RawDescriptionHelpFormatter): """Set maximum text width = 80.""" def __init__(self, prog): width = min(80, shutil.get_terminal_size().columns - 2) argparse.RawDescriptionHelpFormatter.__init__(self, prog, width=width) -- ___ Python tracker <https://bugs.python.org/issue39809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39809] argparse: add max_text_width parameter to ArgumentParser
Luca added the comment: Of course I still think there should be an easier way to do this though. -- ___ Python tracker <https://bugs.python.org/issue39809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39809] argparse: add max_text_width parameter to ArgumentParser
Luca added the comment: I opened two issues regarding the mypy error, I understand it is going to be fixed in typeshed: https://github.com/python/mypy/issues/8487 https://github.com/python/typeshed/issues/3806 -- ___ Python tracker <https://bugs.python.org/issue39809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39809] argparse: add max_text_width parameter to ArgumentParser
Luca added the comment: The issue has been fixed in `typeshed`, so the following is now allowed: width = min(80, shutil.get_terminal_size().columns - 2) formatter_class = lambda prog: argparse.RawDescriptionHelpFormatter(prog, width=width) https://github.com/python/typeshed/issues/3806#event-3104796040 -- ___ Python tracker <https://bugs.python.org/issue39809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16535] json encoder unable to handle decimal
Change by Luca Lesinigo : -- nosy: +luca.lesinigo ___ Python tracker <https://bugs.python.org/issue16535> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12840] "maintainer" value clear the "author" value when register
New submission from Luca Fabbri : I reported this problem in the pypi site issue tracker (issue 3396924): https://sourceforge.net/tracker/?func=detail&atid=513503&aid=3396924&group_id=66150 However it seems that is a python bug. If in one package's setup.py I provide maintainer (with email) and author (whit email) after the "python setup.py register ... upload" I create a new package where I see the maintainer as a creator. If I manually fix it through the pypi user interface all works, so seems that this is only a bug of the register procedure. -- assignee: tarek components: Distutils messages: 142959 nosy: eric.araujo, keul, tarek priority: normal severity: normal status: open title: "maintainer" value clear the "author" value when register type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue12840> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12840] "maintainer" value clear the "author" value when register
Luca Fabbri added the comment: I'm quite sure that after gettint ownership on an already existent package (with a different author inside) and I added the maintainer (with my name) I get the author override. But maybe I don't remember exactly... Is not simpler (to understand) to keep always the approach to keep both? -- ___ Python tracker <http://bugs.python.org/issue12840> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44292] contextmanager + ExitStack.pop_all()
New submission from Luca Mattiello :
Reading the contextlib documentation, one might assume the following to be
functionally equivalent, when used in a with statement:
@contextlib.contextmanager
def managed_resource():
resource = acquire()
try:
yield resource
finally:
resource.release()
class ManagedResource:
def __init__(self):
self.resource = acquire()
def __enter__(self):
return self.resource
def __exit__(self, *args):
self.resource.release()
However, the first version has a seemingly unexpected behavior when used in
conjunction with an ExitStack, and pop_all().
with contextlib.ExitStack() as es:
r = es.enter_context(managed_resource())
es.pop_all()
# Uh-oh, r gets released anyway
with contextlib.ExitStack() as es:
r = es.enter_context(ManagedResource())
es.pop_all()
# Works as expected
I think the reason is
https://docs.python.org/3/reference/expressions.html#yield-expressions, in
particular
> Yield expressions are allowed anywhere in a try construct.
> If the generator is not resumed before it is finalized (by
> reaching a zero reference count or by being garbage collected),
> the generator-iterator’s close() method will be called,
> allowing any pending finally clauses to execute.
I guess this is working according to the specs, but I found it very
counter-intuitive. Could we improve the documentation to point out this subtle
difference?
Full repro:
import contextlib
@contextlib.contextmanager
def cm():
print("acquire cm")
try:
yield 1
finally:
print("release cm")
class CM:
def __init__(self):
print("acquire CM")
def __enter__(self):
return 1
def __exit__(self, *args):
print("release CM")
def f1():
with contextlib.ExitStack() as es:
es.enter_context(cm())
es.pop_all()
def f2():
with contextlib.ExitStack() as es:
es.enter_context(CM())
es.pop_all()
f1()
f2()
Output:
acquire cm
release cm
acquire CM
--
assignee: docs@python
components: Documentation, Library (Lib)
messages: 394948
nosy: docs@python, lucae.mattiello
priority: normal
severity: normal
status: open
title: contextmanager + ExitStack.pop_all()
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44292>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39140] shutil.move does not work properly with pathlib.Path objects
New submission from Luca Paganin :
Suppose you have two pathlib objects representing source and destination of a
move:
src=pathlib.Path("foo/bar/barbar/myfile.txt")
dst=pathlib.Path("foodst/bardst/")
If you try to do the following
shutil.move(src, dst)
Then an AttributeError will be raised, saying that PosixPath objects do not
have an rstrip attribute. The error is the following:
Traceback (most recent call last):
File "mover.py", line 10, in
shutil.move(src, dst)
File "/Users/lucapaganin/opt/anaconda3/lib/python3.7/shutil.py", line 562, in
move
real_dst = os.path.join(dst, _basename(src))
File "/Users/lucapaganin/opt/anaconda3/lib/python3.7/shutil.py", line 526, in
_basename
return os.path.basename(path.rstrip(sep))
AttributeError: 'PosixPath' object has no attribute 'rstrip'
Looking into shutil code, line 526, I see that the problem happens when you try
to strip the trailing slash using rstrip, which is a method for strings, while
PosixPath objects do not have it. Moreover, pathlib.Path objects already manage
for trailing slashes, correctly getting basenames even when these are present.
The following two workarounds work:
1) Explicit cast both src and dst as string using
shutil.move(str(src), str(dst))
This work for both the cases in which dst contains the destination filename or
not.
2) Add the filename to the end of the PosixPath dst object:
dst=pathlib.Path("foodst/bardst/myfile.txt")
Then do
shutil.move(src, dst)
Surely one could use the method pathlib.Path.replace for PosixPath objects,
which does the job without problems, even if it requires for dst to contain the
destination filename at the end, and lacks generality, since it bugs when one
tries to move files between different filesystems.
I think that you should account for the possibility for shutil.move to manage
pathlib.Path objects even if one does not provide the destination filename,
since the source of the bug is due to a safety measure which is not necessary
for pathlib.Path objects, i.e. the managing of the trailing slash.
Do you think that is possible? Thank you in advance.
Luca Paganin
P.S.: I attach a tarball with the dirtree I used for the demonstration.
--
files: mover.tgz
messages: 358891
nosy: Luca Paganin
priority: normal
severity: normal
status: open
title: shutil.move does not work properly with pathlib.Path objects
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48803/mover.tgz
___
Python tracker
<https://bugs.python.org/issue39140>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40633] json.dumps() should encode float number NaN to null
Luca Barba added the comment: I agree with arjanstaring This implementation is not standard compliant and breaks interoperability with every ECMA compliant Javascript deserializer. Technically is awful of course but interoperability and standardization come before than technical cleanliness IMHO Regarding standardization: If you consider https://tools.ietf.org/html/rfc7159 there is no way to represent the literal "nan" with the grammar supplied in section 6 hence the Infinity and Nan values are forbidden so as "nan" For interoperability If you consider http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf It is clearly stated in section 24.5.2 Note 4 that JSON.stringify produces null for Infinity and NaN "Finite numbers are stringified as if by calling ToString(number). NaN and Infinity regardless of sign are represented as the String null" It is clearly stated in section 24.5.1 that JSON.parse uses eval-like parsing as a reference for decoding. nan is not an allowed keyword at all. For interoperability NaN could be used but out from the JSON standard. So what happens is that this will break all the ECMA compliant parsers (aka browsers) in the world. Which is what is happening to my project by the way Pandas serialization methos (to_json) already adjusts this issue, but I really think the standard should too -- nosy: +alucab ___ Python tracker <https://bugs.python.org/issue40633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15372] Python is missing alternative for common quoting character
New submission from Luca Fabbri :
Using the unicodedata.decomposition function on characters like \u201c and
\u201d I didn't get back the classic quote character (").
This is a very common error when text is taken from Microsoft Word (where in
italian language a couple of quoting character in a sentence like "foo" is
automatically changed to “foo”).
--
components: Unicode
messages: 165630
nosy: ezio.melotti, keul
priority: normal
severity: normal
status: open
title: Python is missing alternative for common quoting character
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue15372>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22361] Ability to join() threads in concurrent.futures.ThreadPoolExecutor
New submission from Luca Falavigna:
I have a program which waits for external events (mostly pyinotify events), and
when events occur a new worker is created using
concurrent.futures.ThreadPoolExecutor. The following snippet represents shortly
what my program does:
from time import sleep
from concurrent.futures import ThreadPoolExecutor
def func():
print("start")
sleep(10)
print("stop")
ex = ThreadPoolExecutor(1)
# New workers will be scheduled when an event
# is triggered (i.e. pyinotify events)
ex.submit(func)
# Dummy sleep
sleep(60)
When func() is complete, I'd like the underlying thread to be terminated. I
realize I could call ex.shutdown() to achieve this, but this would prevent me
from adding new workers in case new events occur. Not calling ex.shutdown()
leads to have unfinished threads which pile up considerably:
(gdb) run test.py
Starting program: /usr/bin/python3.4-dbg test.py
[Thread debugging using libthread_db enabled]
[New Thread 0x7688e700 (LWP 17502)]
start
stop
^C
Program received signal SIGINT, Interrupt.
0x76e41963 in select () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) info threads
Id Target Id Frame
2Thread 0x7688e700 (LWP 17502) "python3.4-dbg" 0x77bce420 in
sem_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
* 1Thread 0x77ff1700 (LWP 17501) "python3.4-dbg" 0x76e41963 in
select () from /lib/x86_64-linux-gnu/libc.so.6
(gdb)
Would it be possible to add a new method (or a ThreadPoolExecutor option) which
allows to join the underlying thread when the worker function returns?
--
components: Library (Lib)
messages: 226569
nosy: dktrkranz
priority: normal
severity: normal
status: open
title: Ability to join() threads in concurrent.futures.ThreadPoolExecutor
type: enhancement
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue22361>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22361] Ability to join() threads in concurrent.futures.ThreadPoolExecutor
Luca Falavigna added the comment: There is indeed little benefit in freeing up resources left open by a unused thread, but it could be worth closing it for specific needs (e.g. thread processes sensible information) or in embedded systems with very low resources. -- ___ Python tracker <http://bugs.python.org/issue22361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19023] ctypes docs: Unimplemented and undocumented features
Changes by Luca Faustin : -- nosy: +faustinl ___ Python tracker <http://bugs.python.org/issue19023> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5525] Problem with email.MIME* library, using wrong new line
New submission from Luca clementi : I'm running Python 2.5.2 under Ubuntu 8.10. In the file email/generator.py from the core library at line 228 in the function _handle_multipart() # delimiter transport-padding CRLF print >> self._fp, '\n--' + boundary but if this function is run under Unix it print only the LF and not the CRLF as by required by the standard. My guess is that this error is also in other part of the library. SMTP (as HTTP) requires CRLF as new line, by standard, while I see that at the beginning of the generator.py NL = '\n' Am I missing something? Luca -- components: Library (Lib) messages: 83851 nosy: lclement severity: normal status: open title: Problem with email.MIME* library, using wrong new line type: behavior versions: Python 2.5 ___ Python tracker <http://bugs.python.org/issue5525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5525] Problem with email.MIME* library, using wrong new line
Luca clementi added the comment: I forgot to say that the \n should be substitute with \r\n CRLF Luca -- ___ Python tracker <http://bugs.python.org/issue5525> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27334] pysqlite3 context manager not performing rollback when a database is locked elsewhere for non-DML statements
New submission from Luca Citi:
I have reported this bug to the pysqlite module for python2 (
https://github.com/ghaering/pysqlite/issues/103 ) but I also report it here
because it applies to python3 too.
The pysqlite3 context manager does not perform a rollback when a transaction
fails because the database is locked by some other process performing non-DML
statements (e.g. during the sqlite3 command line .dump method).
To reproduce the problem, open a terminal and run the following:
```bash
sqlite3 /tmp/test.db 'drop table person; create table person (id integer
primary key, firstname varchar)'
echo -e 'begin transaction;\nselect * from person;\n.system sleep
1000\nrollback;' | sqlite3 /tmp/test.db
```
Leave this shell running and run the python3 interpreter from a different
shell, then type:
```python
import sqlite3
con = sqlite3.connect('/tmp/test.db')
with con:
con.execute("insert into person(firstname) values (?)", ("Jan",))
pass
```
You should receive the following:
```
1 with con:
2 con.execute("insert into person(firstname) values (?)",
("Jan",))
> 3 pass
4
OperationalError: database is locked
```
Without exiting python, switch back to the first shell and kill the `'echo ...
| sqlite3'` process. Then run:
```bash
sqlite3 /tmp/test.db .dump
```
you should get:
```
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
/ ERROR: (5) database is locked */
ROLLBACK; -- due to errors
```
This means that the python process never executed a `rollback` and is still
holding the lock. To release the lock one can exit python (clearly, this is not
the intended behaviour of the context manager).
I believe the reason for this problem is that the exception happened in the
implicit `commit` that is run on exiting the context manager, rather than
inside it. In fact the exception is in the `pass` line rather than in the
`execute` line. This exception did not trigger a `rollback` because the it
happened after `pysqlite_connection_exit` checks for exceptions.
The expected behaviour (pysqlite3 rolling back and releasing the lock) is
recovered if the initial blocking process is a Data Modification Language (DML)
statement, e.g.:
```bash
echo -e 'begin transaction; insert into person(firstname) values
("James");\n.system sleep 1000\nrollback;' | sqlite3 /tmp/test.db
```
because this raises an exception at the `execute` time rather than at `commit`
time.
To fix this problem, I think the `pysqlite_connection_exit` function in
src/connection.c should handle the case when the commit itself raises an
exception, and invoke a rollback. Please see patch attached.
--
components: Extension Modules
files: fix_pysqlite_connection_exit.patch
keywords: patch
messages: 268678
nosy: lciti
priority: normal
severity: normal
status: open
title: pysqlite3 context manager not performing rollback when a database is
locked elsewhere for non-DML statements
versions: Python 3.6
Added file: http://bugs.python.org/file43420/fix_pysqlite_connection_exit.patch
___
Python tracker
<http://bugs.python.org/issue27334>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17527] PATCH as valid request method in wsgiref.validator
New submission from Luca Sbardella: http://tools.ietf.org/html/rfc5789 -- components: Library (Lib) files: validate.patch keywords: patch messages: 185031 nosy: lsbardel priority: normal severity: normal status: open title: PATCH as valid request method in wsgiref.validator type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file29552/validate.patch ___ Python tracker <http://bugs.python.org/issue17527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
