GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GeezerVison is showing github.com — gh-133548: fix handling of empty and 1-item tuples for `sys.exit` by picnixz · Pull Request #135789 · python/cpython Conversation
|
|
🤖 New build scheduled with the buildbot fleet by @picnixz for commit ae37e95 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F135789%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-refleak-buildbots label again. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
bcc2970 to
6b65314
Compare
| } | ||
| else { | ||
| PyErr_SetObject(PyExc_SystemExit, status); | ||
| } |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Isn't this a problem with how PyErr_SetObject creates the exception? Shouldn't it be fixed there?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I think it's a bit unfortunate because that's how _PyErr_CreateException handles tuples:
static PyObject* _PyErr_CreateException(PyObject *exception_type, PyObject *value) { PyObject *exc; if (value == NULL || value == Py_None) { exc = _PyObject_CallNoArgs(exception_type); } else if (PyTuple_Check(value)) { exc = PyObject_Call(exception_type, value, NULL); } else { exc = PyObject_CallOneArg(exception_type, value); } if (exc != NULL && !PyExceptionInstance_Check(exc)) { PyErr_Format(PyExc_TypeError, "calling %R should have returned an instance of " "BaseException, not %s", exception_type, Py_TYPE(exc)->tp_name); Py_CLEAR(exc); } return exc; }
Unless you want me to change _PyErr_CreateException to prevent the fast paths, it could be annoying for downstream users.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Changing PyErr_SetObject() is a much larger change, it should be carefully prepared since it would affect many C extensions.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
| if (PyTuple_Check(status)) { | ||
| /* Make sure that tuples are not flattened during normalization. */ | ||
| /* Make sure that tuples are not flattened during normalization | ||
| * due to the fast path for tuples in _PyErr_CreateException(). */ |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
It's not a "fast path" if removing it changes behaviour. We need to understand whether _PyErr_CreateException has a bug or not.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
This PR is stale because it has been open for 30 days with no activity. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I like this approach but I have remarks on the implementation.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| * Several error messages incorrectly using the term "argument" have been corrected. | ||
| (Contributed by Stan Ulbrych in :gh:`133382`.) | ||
|
|
||
| * :func:`sys.exit` and :exc:`SystemExit` now correctly handle empty and 1-item |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
There is no need to mention SystemExit, the PR only changes sys.exit().
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| * due to the fast path for tuples in _PyErr_CreateException(). */ | ||
| PyObject *exc = PyObject_CallOneArg(PyExc_SystemExit, status); | ||
| PyErr_SetObject(PyExc_SystemExit, exc); | ||
| Py_DECREF(exc); |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
exc can be NULL. You can use:
PyObject *exc = PyObject_CallOneArg(PyExc_SystemExit, status); if (exc != NULL) { PyErr_SetObject(PyExc_SystemExit, exc); Py_DECREF(exc); }
I don't think that we need a special path if PyTuple_Check(). Use the same code path for any status.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| } | ||
| else { | ||
| PyErr_SetObject(PyExc_SystemExit, status); | ||
| } |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Changing PyErr_SetObject() is a much larger change, it should be carefully prepared since it would affect many C extensions.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
This PR is stale because it has been open for 90 days with no activity. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.