[issue46759] sys.excepthook documentation doesn't mention that it isn't called for SystemExit
New submission from Colin Watson : In https://bugs.debian.org/1005803, Matthew Vernon reports that the library documentation for sys.excepthook doesn't mention the detail that that sys.excepthook isn't called for uncaught SystemExit exceptions, although help(sys) does mention this. (He also mentions that help(sys.excepthook) doesn't mention this. I think this would make less sense, since that gets the docstring of a particular implementation of an excepthook - on a given system it might not be Python's built-in version, for instance. But adding information to the main library documentation seems reasonable.) -- assignee: docs@python components: Documentation messages: 413285 nosy: cjwatson, docs@python priority: normal severity: normal status: open title: sys.excepthook documentation doesn't mention that it isn't called for SystemExit versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46759] sys.excepthook documentation doesn't mention that it isn't called for SystemExit
Change by Colin Watson : -- keywords: +patch pull_requests: +29507 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31357 ___ Python tracker <https://bugs.python.org/issue46759> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1703592] have a way to ignore nonexisting locales in locale.setlocale
Colin Watson added the comment:
Yes, the same symptoms are still present.
I'd argue that it generally isn't an error in practice for applications, and
thus the net effect of this exception is negative; it's extraordinarily rare
for a crash to be preferable to running without localisation. Adding a new
function would help because I think it would be easier to persuade people to
call a new function that just does what they want ("turn on localisation if
possible") than to catch an exception (at which point they have to think "hm,
could that exception be for some other reason than
you-just-don't-have-that-locale", etc.).
--
___
Python tracker
<http://bugs.python.org/issue1703592>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1652] subprocess should have an option to restore SIGPIPE to default action
New submission from Colin Watson: On Unix, Python sets SIGPIPE to SIG_IGN on startup, because it prefers to check every write and raise an IOError exception rather than taking SIGPIPE. This is all well and good for Python itself. However, non-Python Unix subprocesses generally expect to have SIGPIPE set to the default action, since that's what will happen if they're started from a normal shell. If this is not the case, then rather than taking SIGPIPE when a write fails due to the reading end of a pipe having been closed, write will return EPIPE and it's up to the process to check that. Many programs are lazy and fail to check for write errors, but in the specific case of pipe closure they are fine when invoked from a normal shell because they rely on taking the signal. Even correctly written programs that diligently check for write errors will typically produce different (and confusing) output when SIGPIPE is ignored. For instance, an example only very slightly adapted from one in the subprocess documentation: $ dd if=/dev/zero of=bigfile bs=1024 seek=1 count=1 1+0 records in 1+0 records out 1024 bytes (1.0 kB) copied, 0.000176709 seconds, 5.8 MB/s $ cat bigfile | head -n0 $ cat t.py from subprocess import Popen, PIPE p1 = Popen(["cat", "bigfile"], stdout=PIPE) p2 = Popen(["head", "-n0"], stdin=p1.stdout, stdout=PIPE) output = p2.communicate()[0] $ python t.py cat: write error: Broken pipe In some cases this problem can be much more significant. For instance, it is very common for shell scripts to rely on SIGPIPE's default action in order to behave correctly. A year or two ago I ran into this in OS installer code I was writing in Python, which called some underlying utility code in shell and C to deal with disk partitioning. In the event that the Python code failed to handle an exception, the shell script being run in a subprocess would spiral out of control rather than cleanly exiting at the first sign of trouble. This actually caused massive data loss on several testers' systems and required a quick release to fix (https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/40464 and https://wiki.ubuntu.com/DapperBeta/PartitionTableCorruption). Now obviously this was ultimately my fault for failing to catch the exceptional condition in testing, but this misdesign in Python and the lack of any documentation of this gotcha really didn't help at the time. For the record, the fix was to call this in a preexec_fn: signal.signal(signal.SIGPIPE, signal.SIG_DFL) This is an area of Unix that's very easy to get wrong. I've written my own subprocess handling library in C for another project, and I still found it non-trivial to track this down when it bit me. Since it essentially arises due to an implementation detail of the Python language, I think it should also be Python's responsibility to fix it up when subprocesses are involved. There are many ways to invoke subprocesses in Python, but the new, all-singing, all-dancing one is of course the subprocess module. I think it would be sufficient for that to do the right thing, or at least have an option to do so, and it's certainly the easiest place to add the option. I'm attaching a suggested patch which adds a restore_sigpipe option and documents it in what seem to be all the relevant places. Note that nearly all the examples end up with restore_sigpipe enabled. In some future release of Python, I think this should be the default. I'm not entirely familiar with migration plan processes in Python; how should this be done? -- components: Library (Lib) files: subprocess-sigpipe.patch messages: 58750 nosy: cjwatson severity: normal status: open title: subprocess should have an option to restore SIGPIPE to default action versions: Python 2.5 Added file: http://bugs.python.org/file8986/subprocess-sigpipe.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1652> __Index: Doc/library/subprocess.rst === --- Doc/library/subprocess.rst (revision 59547) +++ Doc/library/subprocess.rst (working copy) @@ -30,7 +30,7 @@ This module defines one class called :class:`Popen`: -.. class:: Popen(args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0) +.. class:: Popen(args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0, restore_sigpipe=False) Arguments are: @@ -112,6 +112,12 @@ underlying CreateProcess() function. They can specify things such as appearance of the main window and pri
[issue1652] subprocess should have an option to restore SIGPIPE to default action
Colin Watson added the comment: To be quite honest I can't think of any incompatibilities that wouldn't have the basic result of improving matters. I put the migration stuff in my bug report in case somebody else could, because I don't want the bug fix to stall on that. My preference would be for Python to move to behaviour equivalent to restore_sigpipe=True in the next release, but I would rather that it gained restore_sigpipe with the wrong default than that it didn't gain it at all. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1652> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1652] subprocess should have an option to restore SIGPIPE to default action
Colin Watson <[EMAIL PROTECTED]> added the comment: 2.6 is fine if that's what the release process dictates; I don't want it to be lost, that's all. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1652> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42669] "except" documentation still suggests nested tuples are allowed
New submission from Colin Watson : In Python 2, it was possible to use `except` with a nested tuple, and occasionally natural. For example, `zope.formlib.interfaces.InputErrors` is a tuple of several exception classes, and one might reasonably think to do something like this (this is real code used in several places in https://git.launchpad.net/launchpad): try: self.getInputValue() return True except (InputErrors, SomethingElse): return False As of Python 3.0, this raises "TypeError: catching classes that do not inherit from BaseException is not allowed" instead: one must instead either break it up into multiple "except" clauses or flatten the tuple. The change was mentioned in https://bugs.python.org/issue2380 and seems to have been intentional: I'm not requesting that the previous behaviour be restored, since it's a fairly rare porting issue and by now well-established in Python 3. However, the relevant sentences of documentation in https://docs.python.org/2/reference/compound_stmts.html#try and https://docs.python.org/3/reference/compound_stmts.html#the-try-statement are identical aside from punctuation, and they both read: For an except clause with an expression, that expression is evaluated, and the clause matches the exception if the resulting object is “compatible” with the exception. An object is compatible with an exception if it is the class or a base class of the exception object or a tuple containing an item compatible with the exception. I think this admits a recursive reading: I certainly read it that way. It should make it clear that nested tuples are not allowed. -- assignee: docs@python components: Documentation messages: 383243 nosy: cjwatson, docs@python priority: normal severity: normal status: open title: "except" documentation still suggests nested tuples are allowed versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42669] "except" documentation still suggests nested tuples are allowed
Change by Colin Watson : -- keywords: +patch pull_requests: +22682 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23822 ___ Python tracker <https://bugs.python.org/issue42669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38634] Symbol resolution conflict when embeding python in an application using libedit
Colin Watson added the comment: FWIW I just ran into what I believe to be this bug with the Launchpad test suite on Python 3.6.9. The output shows some normal test output followed by: No entry for terminal type "unknown"; using dumb terminal settings. bind: Invalid command `enable-meta-key'. No entry for terminal type "unknown"; using dumb terminal settings. No entry for terminal type "unknown"; using dumb terminal settings. Segmentation fault The test suite imports a lot of stuff, but it includes something which links against libLLVM which links against libedit (I haven't worked out exactly what, but probably GTK-related). Then something else much later imports readline - again, I haven't worked out what yet, as it's taken me a day just to set up the exact right environment in which to reproduce this at all and an strace doesn't make the cause of the import especially clear. So I understand why you see this as a rare use case, but it's *extremely* confusing and a massive time sink when you do run across it, as the cause is a long way distant from the effect and it can arise in situations where it is in no way deliberate to have this sort of setup, but rather an emergent effect of several other things. -- nosy: +cjwatson ___ Python tracker <https://bugs.python.org/issue38634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38634] Symbol resolution conflict when embeding python in an application using libedit
Colin Watson added the comment: Here's a reasonably minimal reproduction recipe reduced from real code in the Launchpad test suite that doesn't require compiling a separate C extension. It fails on Ubuntu 18.04 with the gir1.2-gtk-3.0, python3-gi, and xvfb packages installed. (The xvfb-run part is just so that it works on a headless system; you can omit it if you have a working $DISPLAY.) xvfb-run python3 -c 'from gi.repository import Gtk; import readline' -- ___ Python tracker <https://bugs.python.org/issue38634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper
New submission from Colin Watson : The file-like object returned by TarFile.extractfile can't be wrapped in an io.TextIOWrapper (which would be rather convenient in some cases to get something that reads str rather than bytes). The attached patch demonstrates the problem by way of a test case, and fixes it. It's just a matter of adding a no-op flush method so that TextIOWrapper.close is happy with it. -- components: Library (Lib) files: tarfile-exfileobject-flush.patch keywords: patch messages: 151536 nosy: cjwatson priority: normal severity: normal status: open title: tarfile.ExFileObject can't be wrapped using io.TextIOWrapper versions: Python 3.3 Added file: http://bugs.python.org/file24271/tarfile-exfileobject-flush.patch ___ Python tracker <http://bugs.python.org/issue13815> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18108] shutil.chown should support dir_fd and follow_symlinks keyword arguments
New submission from Colin Watson: Python 3.3 added the dir_fd and follow_symlinks keyword arguments to os.chown; it also added the shutil.chown function. Unfortunately the latter, while useful, does not support these new keyword arguments. It would be helpful if it did. -- components: Library (Lib) messages: 190404 nosy: cjwatson priority: normal severity: normal status: open title: shutil.chown should support dir_fd and follow_symlinks keyword arguments versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue18108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1652] subprocess should have an option to restore SIGPIPE to default action
Colin Watson added the comment: Is there anything more I can do to move this along? Thanks. -- ___ Python tracker <http://bugs.python.org/issue1652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
