[issue34086] logging.Handler.handleError regressed in python3
New submission from Oren :
In python2, calling Handler.handleError may not be strictly correct, but it
doesn't raise an exception. However, this has regressed since this patch:
https://hg.python.org/cpython/rev/d7b868cdd9bb
$ cat logbug.py
import logging
class CustomHandler(logging.Handler):
def transmit(self, record):
return False
def emit(self, record):
if not self.transmit(record):
self.handleError(record)
def main():
logger = logging.getLogger()
logger.addHandler(CustomHandler())
logger.warning('this will work in python 2.7, but not 3')
if __name__ == '__main__':
main()
$ python2 logbug.py
None
Logged from file logbug.py, line 15
$ python3 logbug.py
--- Logging error ---
NoneType: None
Call stack:
Traceback (most recent call last):
File "logbug.py", line 20, in
main()
File "logbug.py", line 15, in main
logger.warning('this will work in python 2.7, but not 3')
File
"/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
line 1318, in warning
self._log(WARNING, msg, args, **kwargs)
File
"/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
line 1442, in _log
self.handle(record)
File
"/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
line 1452, in handle
self.callHandlers(record)
File
"/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
line 1514, in callHandlers
hdlr.handle(record)
File
"/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
line 863, in handle
self.emit(record)
File "logbug.py", line 9, in emit
self.handleError(record)
File
"/usr/local/opt/python3/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py",
line 920, in handleError
frame = tb.tb_frame
AttributeError: 'NoneType' object has no attribute 'tb_frame'
--
components: Library (Lib)
messages: 321391
nosy: orenl
priority: normal
severity: normal
status: open
title: logging.Handler.handleError regressed in python3
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue34086>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34086] logging.Handler.handleError regressed in python3
Oren added the comment:
I realize that there is a legitimate argument that handleError() is being used
wrong in the example, but since it used to work, it'd be nice if it still did.
I came across this after converting a codebase to python3 and it took a while
for this problem to appear.
I propose the following fix:
$ git diff
diff --git a/Lib/logging/__init__.py b/Lib/logging/__init__.py
index 29a7d46..f2c3023 100644
--- a/Lib/logging/__init__.py
+++ b/Lib/logging/__init__.py
@@ -908,7 +908,7 @@ class Handler(Filterer):
sys.stderr.write('Call stack:\n')
# Walk the stack frame up until we're out of logging,
# so as to print the calling context.
-frame = tb.tb_frame
+frame = tb and tb.tb_frame
while (frame and os.path.dirname(frame.f_code.co_filename) ==
__path__[0]):
frame = frame.f_back
This results in:
$ python3 logbug.py
--- Logging error ---
NoneType: None
Call stack:
Logged from file logbug.py, line 15
Message: 'this will work in python 2.7, but not 3'
Arguments: ()
--
___
Python tracker
<https://bugs.python.org/issue34086>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34086] logging.Handler.handleError regressed in python3
Change by Oren : -- nosy: +vinay.sajip ___ Python tracker <https://bugs.python.org/issue34086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34086] logging.Handler.handleError regressed in python3
Oren added the comment: I totally agree that this involves misusing handleError. I ended up fixing the code that originally caused the problem, since it was wrong in the first place. The reason I filed this bug and that I think it's worth fixing is that in previous versions, the problem would be that something might not get logged as expected; now the problem turns into a crash. Not only is it now a crash, but the code that crashes requires something else to go wrong (we're not calling handleError() because everything went right), which means that applications that previously tolerated something going wrong, now break. If the necessary fix was complicated, I could see the wisdom in not fixing it, but since it's simple, why not? -- ___ Python tracker <https://bugs.python.org/issue34086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34086] logging.Handler.handleError regressed in python3
Oren added the comment: The code that was causing this problem looked something like: -- def emit(self, record): ... response = requests.post(...) if not response.ok: self.handleError(record) ... -- In this case, something does apparently go wrong, but it doesn't actually involve an exception. I assume that I'm not the only person in the world dealing with a code base where handleError was misused like this. Here's some evidence that this is true: https://www.programcreek.com/python/example/619/logging.Handler (search for handleError in the page) -- ___ Python tracker <https://bugs.python.org/issue34086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34086] logging.Handler.handleError regressed in python3
Oren added the comment: You're right - I misread those examples, sorry about that. It looks like my former colleague may have invented the bad code in question. I'm ok with closing as "not a bug" - I do think not fixing it adds a small potential friction for people upgrading their version of python, but maybe raising an exception is an improvement over silently doing the wrong thing? -- ___ Python tracker <https://bugs.python.org/issue34086> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9035] os.path.ismount on windows doesn't support windows mount points
Oren Held added the comment: Anything wrong with the following simple approach? (e.g. is it bad to depend on win32file?) def win_ismount(path): import win32file volume_path = win32file.GetVolumePathName(path) return volume_path == path # May have to ignore a trailing backslash -- ___ Python tracker <http://bugs.python.org/issue9035> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11102] configure doesn't find "major()" on HP-UX v11.31
Oren Held added the comment: Any tip on how to make this patch get committed? :) -- ___ Python tracker <http://bugs.python.org/issue11102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1516897] Use dynload_shlib on newer HP-UX versions
Oren Held added the comment: ajaksu2: the ticket you referred to fixed it for Darwin only, afaik. HP-UX, regardless of versions, still use the old dynload_hpux.c. -- nosy: +Oren_Held ___ Python tracker <http://bugs.python.org/issue1516897> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1487481] Could BIND_FIRST be removed on HP-UX?
Changes by Oren Held : -- nosy: +Oren_Held ___ Python tracker <http://bugs.python.org/issue1487481> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7242] Forking in a thread raises RuntimeError
Oren Held added the comment: Just adding some info: This bug is not Solaris-specific; I reproduced it on HP-UX 11.31. On Python 2.6.4, thread_test.py fails with the same RunTime error exception. On Python 2.6.6, it passes and things look good. -- nosy: +Oren_Held ___ Python tracker <http://bugs.python.org/issue7242> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10800] libffi build failure on HP-UX 11/PA
Oren Held added the comment: I confirm that on Python 2.7.1, on HP-UX 11.31, ia64 architecture). dlmalloc.c is the problematic file, a part of libffi. I reported the same problem and solution + patch in here: http://sourceware.org/ml/libffi-discuss/2010/msg00203.html -- nosy: +Oren_Held versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue10800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11047] Bad description for a change
New submission from Oren Held : In the "what's new in 2.7", there is some mistake in the description of issue 7902. 7902, afaik, disables the fallback to absolute import, when requesting a relative import fails. If I got it right, the description states the opposite. -- assignee: docs@python components: Documentation files: whatsnew_issue_7902_fix.patch keywords: patch messages: 127317 nosy: Oren_Held, docs@python priority: normal severity: normal status: open title: Bad description for a change versions: Python 2.7 Added file: http://bugs.python.org/file20577/whatsnew_issue_7902_fix.patch ___ Python tracker <http://bugs.python.org/issue11047> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11102] configure doesn't find "major()" on HP-UX v11.31
New submission from Oren Held : The effect eventually is that on HP-UX v3 there are no os.major() and os.minor() functions. I tried to dig deeper to find out what's wrong, and it seems that 'configure' script fails on 'major' check and thus disables the 'major' feature: 'configure' finds well that /usr/include/sys/sysmacros.h has makedev(), major(), minor() definitions (MAJOR_IN_SYSMACROS==1). The problem is that including sys/sysmacros.h is not enough, it depends (but doesn't #include) sys/types.h for the definition of dev_t (needed by makedev() macro). See attached config.log for configure's behavior. -- components: Build files: config.log messages: 127757 nosy: Oren_Held priority: normal severity: normal status: open title: configure doesn't find "major()" on HP-UX v11.31 versions: Python 2.7 Added file: http://bugs.python.org/file20652/config.log ___ Python tracker <http://bugs.python.org/issue11102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11102] configure doesn't find "major()" on HP-UX v11.31
Oren Held added the comment: Attaching a patch I've made for fixing the problem in HP-UX, simply by #including sys/types.h on the configure test.. 1. I'm not sure it'll be good for all platforms; maybe we need more 'configure' magic here to make it #include on this configure test only when needed (e.g. HP-UX v3). 2. Once 'configure' decides to enable the "os.major" feature, 'make' simply compiles it well - I didn't have to fix things in Modules/posixmodule.c (apparently sys/types.h is already loaded). I'm not sure it's smart to count on it. -- keywords: +patch Added file: http://bugs.python.org/file20653/python-configure-hpux-major-fix.patch ___ Python tracker <http://bugs.python.org/issue11102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11102] configure doesn't find "major()" on HP-UX v11.31
Oren Held added the comment: Just a small note: after this patch applied, building Python 2.7.1 was successful on Linux (SLES 11, RHEL 5, Ubuntu 10.10), Solaris 10, and HP-UX 11 v3. (I didn't get to build Python on other platforms) -- ___ Python tracker <http://bugs.python.org/issue11102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10800] libffi build failure on HP-UX 11/PA
Oren Held added the comment: quick update: libffi (upstream) has this fixed now in git commit dc411e8f991 . -- ___ Python tracker <http://bugs.python.org/issue10800> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3676] Obsolete references to PEP 291 in py3k lib
New submission from Oren Tirosh <[EMAIL PROTECTED]>: The comments in the following modules contain references to PEP 291 or to remaining compatible with version 2.x. However, they all include non backward compatible python 3 syntax like "except x as y". decimal.py modulefinder.py pkgutil.py subprocess.py -- components: Library (Lib) messages: 71921 nosy: orent severity: normal status: open title: Obsolete references to PEP 291 in py3k lib versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3676> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7902] relative import broken
Changes by Oren Held : -- nosy: +Oren_Held ___ Python tracker <http://bugs.python.org/issue7902> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8599] _execvpe should behaves inconsistently when PATH includes a filename
New submission from Oren Held :
A. Description
When running os._execvpe with a relative pathname that does not exist, I'd
expect to get ENOENT error. But there is an edge case in which Python throws
ENOTDIR error - when the LAST element in PATH is a regular file (e.g. /bin/ls).
This case is caused by a sysadmin mistake, but it may happen, as in the system
on which I've encountered this bug.
B. Explanation + How to reproduce:
Consider the following case:
PATH="/bin:/bin/ls" # Last part is a filename instead of a directory
>>> import os; os.execvp("blabla", [""])
Throws: OSError: [Errno 20] Not a directory
Now, consider a similar but differently-ordered PATH:
PATH="/bin/ls:/bin" # *First* part is a filename instead of a directory
>>> import os; os.execvp("blabla", [""])
Throws: OSError: [Errno 2] No such file or directory
C. Why this behavior is not good:
First, IMO there is a certain problem here - differently ordered PATH shouldn't
throw different exception. In both cases the executable was not found in PATH,
both cases are the same for this matter.
Second, the unix shell (e.g. bash) faces the same issue, and behaves
differently. It'll return "command not found" to stdout for both ENOENT and
ENOTDIR cases, regardless of the element order in PATH.
D. My recommendation
I'd recommend throwing ENOENT even when ENODIR is thrown for some paths. I am
not sure what's the least-evil way to do it, I've been thinking of the
following patch, but it's not working because it depends on strerror. It also
looks kinda ugly:
--- os.py.old 2010-05-02 17:41:21.481909804 +0300
+++ os.py 2010-05-02 18:03:11.261872651 +0300
@@ -386,7 +386,7 @@
saved_tb = tb
if saved_exc:
raise error, saved_exc, saved_tb
-raise error, e, tb
+raise error, error(errno.ENOENT, os.strerror(errno.ENOENT)), tb # DOESNT
WORK, no access to os.strerror from here
# Change environ to automatically call putenv() if it exists
try:
--
components: Library (Lib)
messages: 104788
nosy: Oren_Held
priority: normal
severity: normal
status: open
title: _execvpe should behaves inconsistently when PATH includes a filename
type: behavior
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue8599>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8599] _execvpe behaves inconsistently when PATH includes a filename
Changes by Oren Held : -- title: _execvpe should behaves inconsistently when PATH includes a filename -> _execvpe behaves inconsistently when PATH includes a filename ___ Python tracker <http://bugs.python.org/issue8599> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15988] Inconsistency in overflow error messages of integer argument
Oren Milman added the comment: How do we proceed? should I update (if needed) each of the patches I uploaded in March to eliminate commit conflicts? or can someone review them as they are now? -- ___ Python tracker <http://bugs.python.org/issue15988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31147] a mostly useless check in list_extend()
New submission from Oren Milman:
in listobject.c, in case list_extend() receives an 'iterable' which isn't 'self'
nor a tuple nor a list, we have the following (heavily edited for brevity):
mn = Py_SIZE(self) + PyObject_LengthHint(iterable);
list_resize(self, mn);
... // self is extended to also include the elements of 'iterable'.
// (*)
if (Py_SIZE(self) < self->allocated) {
list_resize(self, Py_SIZE(self));
}
IMHO, the condition in (*) is mostly useless, for two reasons:
1. the list_resize() which is called in (*) does nothing in case
(Py_SIZE(self) >= (self->allocated >> 1)) is true. In particular, this call
to list_resize() would have done nothing if it had been called while the
condition in (*) was false.
2. the condition in (*) is false only in the following cases:
- list_resize(self, mn) caused
(self->allocated == Py_SIZE(self) + actual_length_of_iterable) to be
true. e.g.:
Py_SIZE(self) = 58 and PyObject_LengthHint(iterable) == 8 and
actual_length_of_iterable == 22
(because 66 + 66 // 8 + 6 == 80 == 58 + 22).
- list_resize(self, mn) caused
(self->allocated < Py_SIZE(self) + actual_length_of_iterable), which
sometime later caused list_extend() to call app1(), which called
list_resize(), which caused
(self->allocated == Py_SIZE(self) + actual_length_of_iterable) to be true.
e.g.:
Py_SIZE(self) == 58 and PyObject_LengthHint(iterable) == 8 and
actual_length_of_iterable == 39
(because 66 + 66 // 8 + 6 == 80 and
81 + 81 // 8 + 6 == 97 == 58 + 39)
so ISTM that the condition is only rarely false, especially as
PyObject_LengthHint(iterable) >= actual_length_of_iterable is usually true
(i guess).
Thus, i believe we should either change the condition in (*) to
(Py_SIZE(self) < (self->allocated >> 1)), or remove it (and always call
list_resize()).
(note that i ignored error cases, as ISTM they are quite irrelevant to the
issue.)
--
components: Interpreter Core
messages: 299933
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: a mostly useless check in list_extend()
type: performance
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31147>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31187] suboptimal code in Py_ReprEnter()
New submission from Oren Milman:
in Objects/object.c, Py_ReprEnter() does the following:
- try to retrieve the Py_Repr list from the thread-state dict.
- in case the list is not in the dict, add it to the dict as an empty list.
- check whether the received object is in the Py_Repr list, even in case the
list was just created, and guaranteed to be empty.
I propose to put this check inside an else clause, so that it wouldn't take
place in case the list is guaranteed to be empty, i.e.:
list = _PyDict_GetItemId(dict, &PyId_Py_Repr);
if (list == NULL) {
list = PyList_New(0);
...
}
else {
i = PyList_GET_SIZE(list);
while (--i >= 0) {
if (PyList_GET_ITEM(list, i) == obj)
return 1;
}
}
I ran the test suite, and it seems that this change doesn't break anything, so
I would be happy to open a PR for it.
--
components: Interpreter Core
messages: 300193
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: suboptimal code in Py_ReprEnter()
type: performance
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31187>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31147] a suboptimal check in list_extend()
Changes by Oren Milman : -- title: a mostly useless check in list_extend() -> a suboptimal check in list_extend() ___ Python tracker <http://bugs.python.org/issue31147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31147] a suboptimal check in list_extend()
Oren Milman added the comment: thank you for the elaborate reply :) do you feel the same about changing the check to (Py_SIZE(self) < (self->allocated >> 1)) ? -- ___ Python tracker <http://bugs.python.org/issue31147> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Oren Milman added the comment: I replied to your comments in Rietveld, Serhiy. (http://bugs.python.org/review/28261) also, i found two places with a quite similar issue: - in Objects/exceptions.c in ImportError_init: >>> ImportError(1, 2, 3, 4, a=5, b=6, c=7) Traceback (most recent call last): File "", line 1, in TypeError: ImportError() takes at most 2 arguments (3 given) - in Python/bltinmodule.c in min_max: >>> min(1, 2, 3, 4, a=5, b=6, c=7) Traceback (most recent call last): File "", line 1, in TypeError: function takes at most 2 arguments (3 given) may I fix them also as part of this issue? -- ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Oren Milman added the comment: After more looking, I found this issue in two more places: - in Modules/itertoolsmodule.c in product_new: >>> itertools.product(0, a=1, b=2, c=3, d=4, e=5, f=6) Traceback (most recent call last): File "", line 1, in TypeError: product() takes at most 1 argument (6 given) - in Python/bltinmodule.c in builtin_print: >>> print(0, a=1, b=2, c=3, d=4, e=5, f=6) Traceback (most recent call last): File "", line 1, in TypeError: print() takes at most 4 arguments (6 given) what do you think? should I open another issue for these and the other two I mentioned in msg300366? -- ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28332] silent truncations in socket.htons and socket.ntohs
Changes by Oren Milman : -- title: Deprecated silent truncations in socket.htons and socket.ntohs. -> silent truncations in socket.htons and socket.ntohs ___ Python tracker <http://bugs.python.org/issue28332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28332] keyword arguments
Changes by Oren Milman : -- title: silent truncations in socket.htons and socket.ntohs -> keyword arguments ___ Python tracker <http://bugs.python.org/issue28332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28332] Deprecated silent truncations in socket.htons and socket.ntohs.
Changes by Oren Milman : -- title: keyword arguments -> Deprecated silent truncations in socket.htons and socket.ntohs. ___ Python tracker <http://bugs.python.org/issue28332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Changes by Oren Milman : -- pull_requests: +3157 ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31229] wrong error messages when too many kwargs are received
New submission from Oren Milman: Some functions produce wrong error messages in case they receive too many keyword arguments: - in Objects/exceptions.c - ImportError_init: >>> ImportError(1, 2, 3, 4, a=5, b=6, c=7) TypeError: ImportError() takes at most 2 arguments (3 given) - in Python/bltinmodule.c - min_max: >>> min(1, 2, 3, 4, a=5, b=6, c=7) TypeError: function takes at most 2 arguments (3 given) >>> max(1, 2, 3, 4, a=5, b=6, c=7) TypeError: function takes at most 2 arguments (3 given) - in Modules/itertoolsmodule.c - product_new: >>> itertools.product(0, a=1, b=2, c=3, d=4, e=5, f=6) TypeError: product() takes at most 1 argument (6 given) - in Python/bltinmodule.c - builtin_print: >>> print(0, a=1, b=2, c=3, d=4, e=5, f=6) TypeError: print() takes at most 4 arguments (6 given) ISTM that changing these error messages to refer to 'keyword arguments' instead of 'arguments' is a possible solution. (e.g. the last one would become 'print() takes at most 4 keyword arguments (6 given)' To do that, I changed two 'takes at most' PyErr_Format calls in Python/getargs.c. I ran the test suite, and it seems that this patch doesn't break anything. The diff file is attached. (I didn't open a PR before hearing your opinion, as ISTM that changing code in getargs.c is a delicate thing.) what do you think? -- components: Interpreter Core messages: 300451 nosy: Oren Milman priority: normal severity: normal status: open title: wrong error messages when too many kwargs are received type: behavior versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue31229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31229] wrong error messages when too many kwargs are received
Changes by Oren Milman : -- keywords: +patch Added file: http://bugs.python.org/file47091/issue31229_ver1.diff ___ Python tracker <http://bugs.python.org/issue31229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31236] improve some error messages of min() and max()
New submission from Oren Milman: currently, we have the following: >>> min(0, a=1) TypeError: 'a' is an invalid keyword argument for this function >>> max(0, a=1) TypeError: 'a' is an invalid keyword argument for this function >>> max(0, a=1, b=2, c=3) TypeError: function takes at most 2 arguments (3 given) >>> min(0, a=1, b=2, c=3) TypeError: function takes at most 2 arguments (3 given) ISTM it would be preferable for min() and max() to have error messages similar to those of int(): >>> int(0, a=1) TypeError: 'a' is an invalid keyword argument for int() >>> int(0, a=1, b=2) TypeError: int() takes at most 2 arguments (3 given) we can achieve this by making a small change in Python/bltinmodule.c in min_max (I would open a PR soon), and by resolving #31229. -- components: IO messages: 300539 nosy: Oren Milman priority: normal severity: normal status: open title: improve some error messages of min() and max() type: behavior versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue31236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31236] improve some error messages of min() and max()
Changes by Oren Milman : -- pull_requests: +3181 ___ Python tracker <http://bugs.python.org/issue31236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29843] errors raised by ctypes.Array for invalid _length_ attribute
Oren Milman added the comment: I am not sure I understood your question, Igor. I compiled with https://github.com/python/cpython/pull/3006, and got: class T(ctypes.Array): _type_ = ctypes.c_int _length_ = 2 ** 1000 Traceback (most recent call last): File "", line 1, in OverflowError: Python int too large to convert to C ssize_t and also: class T(ctypes.Array): _type_ = ctypes.c_int _length_ = -1 Traceback (most recent call last): File "", line 1, in OverflowError: array too large -- ___ Python tracker <http://bugs.python.org/issue29843> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29832] Don't refer to getsockaddrarg in error messages
Changes by Oren Milman : -- pull_requests: +3199 ___ Python tracker <http://bugs.python.org/issue29832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29832] Don't refer to getsockaddrarg in error messages
Oren Milman added the comment: here is a dirty script to test my PR. the script contains tests to anything I managed to test using my Windows 10 and Ubuntu 16.04 VM, i.e. all of the changes, except for the 'unsupported CAN protocol' message, and the changes of the code that handles the PF_SYSTEM family. -- Added file: http://bugs.python.org/file47093/testPatches.py ___ Python tracker <http://bugs.python.org/issue29832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31243] checks whether PyArg_ParseTuple returned a negative int
New submission from Oren Milman:
according to the docs
(https://docs.python.org/3.7/c-api/arg.html?highlight=pyarg_parsetuple#c.PyArg_ParseTuple),
PyArg_ParseTuple
returns true for success or false for failure. I also looked at the
implementation in Python/getargs.c, and it seems that indeed PyArg_ParseTuple
can return only 0 or 1.
however, in some places in the codebase, there are checks whether
PyArg_ParseTuple returned a negative int.
I found a bunch in Modules/_testcapimodule.c, and one in Modules/_io/textio.c
in textiowrapper_read_chunk. (hopefully i haven't missed other places.)
this code crashes because of the check in textiowrapper_read_chunk:
import codecs
import _io
class MyDec():
def getstate(self):
return 420
class MyDecWrapper():
def __call__(self, blabla):
return MyDec()
quopri = codecs.lookup("quopri")
quopri._is_text_encoding = True
quopri.incrementaldecoder = MyDecWrapper()
t = _io.TextIOWrapper(_io.BytesIO(b'aa'),
newline='\n', encoding="quopri")
t.read(42)
I guess all of these checks should be changed to check whether PyArg_ParseTuple
returned 0.
also, before this specific call to PyArg_ParseTuple in textiowrapper_read_chunk,
we should check whether 'state' is a tuple.
Moreover, this call shouldn't produce a wrong error message, as explained in
#28261.
------
components: Interpreter Core
messages: 300613
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: checks whether PyArg_ParseTuple returned a negative int
type: crash
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31243>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Oren Milman added the comment: it seems that I have missed some places which are part of this issue, at least in Modules/_io/textio.c (one of them is mentioned in #31243). also, when fixing these, we should also add a check before the call to PyArg_ParseTuple (in case such check doesn't already exist), to verify the object is indeed a tuple. -- ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31243] checks whether PyArg_ParseTuple returned a negative int
Oren Milman added the comment: yes, soon. (just wanted to hear your opinion before doing that.) -- ___ Python tracker <http://bugs.python.org/issue31243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31229] wrong error messages when too many kwargs are received
Oren Milman added the comment: I already wrote a patch, but I thought it would be better to wait until #31236 is resolved. this is because #31236 would change the error messages of min() and max(), and test_call tests exact error messages in CFunctionCallsErrorMessages, which is where I thought the tests of this issue should be added. -- ___ Python tracker <http://bugs.python.org/issue31229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31243] checks whether PyArg_ParseTuple returned a negative int
Changes by Oren Milman : -- pull_requests: +3208 ___ Python tracker <http://bugs.python.org/issue31243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31229] wrong error messages when too many kwargs are received
Changes by Oren Milman : -- pull_requests: +3218 ___ Python tracker <http://bugs.python.org/issue31229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Changes by Oren Milman : -- pull_requests: +3237 ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
New submission from Oren Milman:
currently, the following causes an assertion in Modules/_io/textio.c in
_io_TextIOWrapper_write_impl() to fail:
import codecs
import io
class BadEncoder():
def encode(self, dummy):
return 42
def _get_bad_encoder(dummy):
return BadEncoder()
quopri = codecs.lookup("quopri")
quopri._is_text_encoding = True
quopri.incrementalencoder = _get_bad_encoder
t = io.TextIOWrapper(io.BytesIO(b'foo'), encoding="quopri")
t.write('bar')
this is because _io_TextIOWrapper_write_impl() doesn't check whether the value
returned by encoder's encode() is a bytes object.
(I would open a PR to fix that soon.)
------
components: IO
messages: 300795
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: an assertion failure in io.TextIOWrapper.write
type: crash
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31271>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
Changes by Oren Milman : -- pull_requests: +3240 ___ Python tracker <http://bugs.python.org/issue31271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
Oren Milman added the comment: Just checked on current 3.6 on my Windows 10. The assertion failes, and it is in line 1337. oh my. -- ___ Python tracker <http://bugs.python.org/issue31271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
Oren Milman added the comment:
As Serhiy pointed out on github, the assertion failure can be easily reproduced
by the following:
import codecs
import io
rot13 = codecs.lookup("rot13")
rot13._is_text_encoding = True
t = io.TextIOWrapper(io.BytesIO(b'foo'), encoding="rot13")
t.write('bar')
--
___
Python tracker
<http://bugs.python.org/issue31271>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Oren Milman added the comment: sure -- ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
Oren Milman added the comment: all three versions do 'self->pending_bytes_count += PyBytes_GET_SIZE(b);', while 'b' is the object the encoder returned. in 3.6 and 3.7, the implementation of PyBytes_GET_SIZE() includes 'assert(PyBytes_Check(op))', but in 2.7, the implementation is 'PyString_GET_SIZE', which is just 'Py_SIZE(op)'. and so, in 2.7 there isn't an assertion failure. Moreover, 'self->pending_bytes_count' is used only to determine whether a flush is needed. so ISTM that probably the bug's only risk is not flushing automatically after writing. note that whenever _textiowrapper_writeflush() is finally called (when the encoder returned a non-string object), it would raise a TypeError by calling string_join() on a non-string object. do you still think we should backport to 2.7? -- ___ Python tracker <http://bugs.python.org/issue31271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31271] an assertion failure in io.TextIOWrapper.write
Changes by Oren Milman : -- pull_requests: +3247 ___ Python tracker <http://bugs.python.org/issue31271> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Changes by Oren Milman : -- pull_requests: +3248 ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28261] wrong error messages when using PyArg_ParseTuple to parse normal tuples
Changes by Oren Milman : -- pull_requests: +3251 ___ Python tracker <http://bugs.python.org/issue28261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()
New submission from Oren Milman:
1.
the following causes an assertion failure in Python/_warnings.c in
show_warning():
import warnings
class BadLoader:
def get_source(self, fullname):
class BadSource:
def splitlines(self):
return [42]
return BadSource()
del warnings._showwarnmsg
warnings.warn_explicit(message='foo', category=ArithmeticError, filename='bar',
lineno=1, module_globals={'__loader__': BadLoader(),
'__name__': 'foobar'})
in short, the assertion failure would happen in warnings.warn_explicit() in case
module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()[lineno-1]
is not a str.
2.
the following raises a SystemError:
import warnings
class BadLoader:
def get_source(self, fullname):
class BadSource:
def splitlines(self):
return 42
return BadSource()
warnings.warn_explicit(message='foo', category=UserWarning, filename='bar',
lineno=42, module_globals={'__loader__': BadLoader(),
'__name__': 'foobar'})
in short, warnings.warn_explicit() raises the SystemError in case
module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()
is not a list.
ISTM that adding a check in warnings_warn_explicit() (in Python/_warnings.c),
to check whether
module_globals['__loader__'].get_source(module_globals['__name__'])
is a str (after existing code found out that it isn't None) would prevent both
the assertion failure and the SystemError.
What do you think? Is it OK to permit get_source() to return only None or a str?
--
components: Interpreter Core
messages: 300892
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: a SystemError and an assertion failure in warnings.warn_explicit()
type: crash
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31285>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()
Oren Milman added the comment: on a second thought, BadSource could be a subclass of str, so maybe we should just check whether module_globals['__loader__'].get_source(module_globals['__name__']).splitlines()[lineno-1] is a str, and whether module_globals['__loader__'].get_source(module_globals['__name__']).splitlines() is a list. -- ___ Python tracker <http://bugs.python.org/issue31285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()
Changes by Oren Milman : -- pull_requests: +3259 ___ Python tracker <http://bugs.python.org/issue31285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31291] an assertion failure in zipimport.zipimporter.get_data()
New submission from Oren Milman:
on Windows, assuming the file 'foo.zip' exists, the following would cause an
assertion failure in Modules/zipimport.c in
zipimport_zipimporter_get_data_impl():
import zipimport
class BadStr(str):
def replace(self, old, new):
return 42
zipimport.zipimporter('foo.zip').get_data(BadStr('bar'))
this is because zipimport_zipimporter_get_data_impl() assumes that
BadStr('bar').replace('/', '\\') is a string.
------
components: Interpreter Core
messages: 300944
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: an assertion failure in zipimport.zipimporter.get_data()
type: crash
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31291>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31291] an assertion failure in zipimport.zipimporter.get_data()
Changes by Oren Milman : -- pull_requests: +3269 ___ Python tracker <http://bugs.python.org/issue31291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()
Oren Milman added the comment: ISTM that your solution is better than mine, Serhiy, so I updated the PR. -- ___ Python tracker <http://bugs.python.org/issue31285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31293] crashes in multiply_float_timedelta() and in truedivide_timedelta_float()
New submission from Oren Milman: both of the following true division and multiplication operations crash the interpreter: import datetime class BadFloat(float): def as_integer_ratio(self): return (1 << 1000) - 1 datetime.timedelta() / BadFloat() datetime.timedelta() * BadFloat() this is because both multiply_float_timedelta() and truedivide_timedelta_float() (in Modules/_datetimemodule.c) assume as_integer_ratio() returns tuple. -- components: Interpreter Core messages: 300954 nosy: Oren Milman priority: normal severity: normal status: open title: crashes in multiply_float_timedelta() and in truedivide_timedelta_float() type: crash versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue31293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31293] crashes in multiply_float_timedelta() and in truedivide_timedelta_float()
Oren Milman added the comment: i am working on a patch. BTW, is there anywhere a list of what counts as an extension module, and what counts as the interpreter core? -- ___ Python tracker <http://bugs.python.org/issue31293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31293] crashes in multiply_float_timedelta() and in truedivide_timedelta_float()
Changes by Oren Milman : -- pull_requests: +3270 ___ Python tracker <http://bugs.python.org/issue31293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31293] crashes in multiply_float_timedelta() and in truedivide_timedelta_float()
Oren Milman added the comment: I guess you meant for me to check whether the following has any problem: import decimal class BadFloat(float): def as_integer_ratio(self): return 1 << 1000 decimal.Decimal.from_float(BadFloat()) so it doesn't crash. if IIUC, this is because the C implementation of Decimal.from_float() is PyDecType_FromFloat(), while the relevant part of it is a call to PyDecType_FromFloatExact(). But PyDecType_FromFloatExact() uses float.as_integer_ratio(), and thus ISTM that the issue doesn't exist there. (also, the following doesn't raise an exception, as expected: import decimal class BadFloat(float): def as_integer_ratio(self): raise RuntimeError decimal.Decimal.from_float(BadFloat()) ) -- ___ Python tracker <http://bugs.python.org/issue31293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31291] an assertion failure in zipimport.zipimporter.get_data()
Oren Milman added the comment: I understand that our goal is to make Python better, not to make me happier :) anyway, I haven't checked, but I am quite sure that similar code might crash the interpreter on a release build of Python. (just wanted to clarify that, as you used the term 'exception'.) -- ___ Python tracker <http://bugs.python.org/issue31291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31291] an assertion failure in zipimport.zipimporter.get_data()
Oren Milman added the comment:
just checked, and indeed on my Windows 10 the original code I posted here
crashes the interpreter.
The patch in the PR undermines duck-typing, and that's why I added a comment
there, stating I wasn't sure about the patch.
an alternate solution would be to simply check whether the return value of
pathname.replace('/', '\') is a str.
do you think I would update the PR to do that?
--
___
Python tracker
<http://bugs.python.org/issue31291>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31243] checks whether PyArg_ParseTuple returned a negative int
Changes by Oren Milman : -- pull_requests: +3275 ___ Python tracker <http://bugs.python.org/issue31243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31243] checks whether PyArg_ParseTuple returned a negative int
Changes by Oren Milman : -- pull_requests: +3276 ___ Python tracker <http://bugs.python.org/issue31243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31291] zipimport.zipimporter.get_data() crashes when path.replace() returns a non-str
Changes by Oren Milman : -- pull_requests: +3287 ___ Python tracker <http://bugs.python.org/issue31291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] SystemError raised by PyCData_setstate() in case __dict__ is not a dict
New submission from Oren Milman:
The following code causes PyCData_setstate() (in Modules/_ctypes/_ctypes.c) to
raise a SystemError:
import ctypes
class BadStruct(ctypes.Structure):
def __dict__(self):
pass
BadStruct().__setstate__({}, b'foo')
this is because PyCData_setstate() assumes that the __dict__ attribute is a
dict.
while we are here, I wonder whether we should change the format given to
PyArg_ParseTuple() to "!Os#", so that the following would raise a TypeError:
import ctypes
class MyStruct(ctypes.Structure):
pass
MyStruct().__setstate__(42, b'foo')
AttributeError: 'int' object has no attribute 'keys'
what do you think?
--
components: Extension Modules
messages: 301034
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: SystemError raised by PyCData_setstate() in case __dict__ is not a dict
type: behavior
versions: Python 3.7
___
Python tracker
<http://bugs.python.org/issue31311>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] SystemError raised by PyCData_setstate() in case __dict__ is not a dict
Oren Milman added the comment: typo - change the format to "O!s#" -- ___ Python tracker <http://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad
Changes by Oren Milman : -- title: SystemError raised by PyCData_setstate() in case __dict__ is not a dict -> a SystemError and a crash in PyCData_setstate() when __dict__ is bad ___ Python tracker <http://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad
Changes by Oren Milman : -- pull_requests: +3298 ___ Python tracker <http://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad
Changes by Oren Milman : -- pull_requests: +3299 ___ Python tracker <http://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad
Changes by Oren Milman : -- components: +ctypes -Extension Modules ___ Python tracker <http://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31315] assertion failure in imp.create_dynamic(), when spec.name is not a string
New submission from Oren Milman: The following code causes an assertion failure in get_encoded_name(), which is called by _PyImport_LoadDynamicModuleWithSpec() (in Python/importdl.c): import imp class BadSpec: name = 42 origin = 'foo' imp.create_dynamic(BadSpec()) this is because _PyImport_LoadDynamicModuleWithSpec() assumes that spec.name is a string. should we fix this (even though imp is deprecated)? -- components: Extension Modules messages: 301050 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failure in imp.create_dynamic(), when spec.name is not a string type: crash versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue31315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31315] assertion failure in imp.create_dynamic(), when spec.name is not a string
Oren Milman added the comment: do you mean that we should fix it to raise a TypeError? the assertion is there, but not explicitly. get_encoded_name() calls PyUnicode_FindChar(), which calls PyUnicode_READY(), which does assert(_PyUnicode_CHECK). so i get: >>> import imp >>> >>> class BadSpec: ... name = 42 ... origin = 'foo' ... >>> imp.create_dynamic(BadSpec()) Assertion failed: PyUnicode_Check(op), file ..\Objects\unicodeobject.c, line 380 -- ___ Python tracker <http://bugs.python.org/issue31315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31315] assertion failure in imp.create_dynamic(), when spec.name is not a string
Changes by Oren Milman : -- pull_requests: +3301 ___ Python tracker <http://bugs.python.org/issue31315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31404] undefined behavior and crashes in case of a bad sys.modules
New submission from Oren Milman: at least on my Windows, the following code: import sys sys.modules = [] - when run interactively, causes weird behavior, e.g. exit() doesn't exit the interpreter, and print() doesn't print. then, pressing Ctrl+C causes 'Assertion failed: !PyErr_Occurred(), file ..\Objects\call.c, line 803' - when run as a script, causes PyImport_Cleanup() to raise a negative ref count Fatal Python error. (this is because PyImport_Cleanup() (in Python/import.c) assumes that PyImport_GetModuleDict() returned a dict.) IIUC, this bug was introduced in https://github.com/python/cpython/pull/1638 (which resolved #28411). -- components: Interpreter Core messages: 301783 nosy: Oren Milman priority: normal severity: normal status: open title: undefined behavior and crashes in case of a bad sys.modules type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31404> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31311] a SystemError and a crash in PyCData_setstate() when __dict__ is bad
Oren Milman added the comment: just in case it was missed - I have opened two PRs for this issue. -- ___ Python tracker <https://bugs.python.org/issue31311> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31406] crashes when comparing between a Decimal object and a bad Rational object
New submission from Oren Milman: The following code crashes the interpreter: import decimal import fractions class BadRational(fractions.Fraction): numerator = None denominator = 42 decimal.Decimal() < BadRational() this is because numerator_as_decimal() (in Modules/_decimal/_decimal.c) assumes that 'numerator' is an integer. multiply_by_denominator() (in Modules/_decimal/_decimal.c) also assumes that 'denominator' is an integer, and so the following code crashes the interpreter: import decimal import fractions class BadRational(fractions.Fraction): numerator = 42 denominator = None decimal.Decimal() < BadRational() -- components: Extension Modules messages: 301809 nosy: Oren Milman priority: normal severity: normal status: open title: crashes when comparing between a Decimal object and a bad Rational object type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31406] crashes when comparing between a Decimal object and a bad Rational object
Changes by Oren Milman : -- keywords: +patch pull_requests: +3467 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31411] SystemError raised by warn_explicit() in case warnings.onceregistry is not a dict
New submission from Oren Milman:
The following code causes warn_explicit() (in Python/_warnings.c) to raise a
SystemError:
import warnings
warnings.filterwarnings('once')
warnings.onceregistry = None
warnings.warn_explicit(message='foo', category=Warning, filename='bar',
lineno=1, registry=None)
this is because warn_explicit() assumes that warnings.onceregistry is a dict,
and passes it to update_registry(), which passes it to already_warned(), which
eventually passes it to _PyDict_SetItemId(), which raises the SystemError.
--
components: Extension Modules
messages: 301822
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: SystemError raised by warn_explicit() in case warnings.onceregistry is
not a dict
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue31411>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31411] SystemError raised by warn_explicit() in case warnings.onceregistry is not a dict
Changes by Oren Milman : -- keywords: +patch pull_requests: +3475 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31416] assertion failures in warn_explicit() in case of a bad warnings.filters or warnings.defaultaction
New submission from Oren Milman: The following code causes an assertion failure in warn_explicit() (in Python/_warnings.c): import warnings warnings.filters = [(None, None, Warning, None, 0)] warnings.warn_explicit(message='foo', category=Warning, filename='bar', lineno=1) this is because warn_explicit() assumes that get_filter() returned a string, and passes the return value (of get_filter()) to _PyUnicode_EqualToASCIIString(), which asserts it received a string. In addition, get_filter() might return warnings.defaultaction, and so the following code also causes an assertion failure in warn_explicit(): import warnings warnings.defaultaction = None warnings.filters = [] warnings.warn_explicit(message='foo', category=Warning, filename='bar', lineno=1) -- components: Extension Modules messages: 301867 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failures in warn_explicit() in case of a bad warnings.filters or warnings.defaultaction type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31416] assertion failures in warn_explicit() in case of a bad warnings.filters or warnings.defaultaction
Changes by Oren Milman : -- keywords: +patch pull_requests: +3489 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31418] assertion failure in PyErr_WriteUnraisable() in case of an exception with a bad __module__
New submission from Oren Milman: The following code causes an assertion failure in PyErr_WriteUnraisable() (in Python/errors.c): class BadException(Exception): __module__ = None class BadClass: def __del__(self): raise BadException foo = BadClass() del foo this is because PyErr_WriteUnraisable() assumes that __module__ is a string, and passes it to _PyUnicode_EqualToASCIIId(), which asserts it received a string. what is the wanted behavior in such a case? should we ignore the bad __module__ and print '' as the module name in the traceback? -- components: Interpreter Core messages: 301872 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failure in PyErr_WriteUnraisable() in case of an exception with a bad __module__ type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31428] ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad memo
New submission from Oren Milman:
The following code causes ElementTree.Element.__deepcopy__() to raise a
SystemError:
class BadMemo:
def get(*args):
return None
import xml.etree.ElementTree
xml.etree.ElementTree.Element('foo').__deepcopy__(BadMemo())
this is because _elementtree_Element___deepcopy__() (in Modules/_elementtree.c)
assumes that memo is a dictionary, and passes it to PyDict_SetItem(), which
raises the SystemError.
--
components: XML
messages: 301953
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad
memo
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue31428>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31428] ElementTree.Element.__deepcopy__() raises a SystemError in case of a bad memo
Changes by Oren Milman : -- keywords: +patch pull_requests: +3507 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue31428> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31442] assertion failures on Windows in Python/traceback.c in case of a bad io.open
New submission from Oren Milman: the following code causes an assertion failure on my Windows: import io def _bad_open(*args): return 42 io.open = _bad_open 1/0 this is because _Py_DisplaySourceLine() (in Python/traceback.c) assumes that the return value of io.open() is valid. IIUC, this is actually a debug assertion failure in Windows code, in _get_osfhandle() (which is called by _Py_dup() (in Python/fileutils.c)). (also, on my Ubuntu VM, there is no assertion failure.) the following code causes a similar assertion failure: import io def _bad_open1(*args): io.open = _bad_open2 raise Exception def _bad_open2(*args): return 42 io.open = _bad_open1 1/0 this is because _Py_FindSourceFile() assumes that the return value of io.open() is valid, and returns it to _Py_DisplaySourceLine(), which also assume it is valid. I thought about adding a check in _Py_DisplaySourceLine(), before calling PyObject_AsFileDescriptor(), such as: PyObject_IsInstance(binary, (PyObject*)&PyIOBase_Type); but I am not sure whether we should use PyIOBase_Type outside of the io module. note that even with such a check, one could still write a _bad_open() that returns a subclass of IOBase, whose fileno() method returns a bad file descriptor. #15263 (and specifically https://bugs.python.org/issue15263#msg164731) mentions this. -- components: IO messages: 302036 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failures on Windows in Python/traceback.c in case of a bad io.open type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31444] ResourceWarning in Python/traceback.c in case of a bad io.TextIOWrapper
New submission from Oren Milman: the following code causes a ResourceWarning: import io def _bad_TextIOWrapper(*args): return None io.TextIOWrapper = _bad_TextIOWrapper 1/0 this is because _Py_DisplaySourceLine() (in Python/traceback.c) assumes that io.TextIOWrapper() returned a stream object, and tries to call its close() method. in case calling close() fails, _Py_DisplaySourceLine() just calls PyErr_Clear(). maybe _Py_DisplaySourceLine() should try to call binary.close() in such cases? I also thought about adding a check such as: PyObject_IsInstance(fob, (PyObject*)&PyTextIOWrapper_Type); but I am not sure whether we should use PyTextIOWrapper_Type outside of the io module. -- components: IO messages: 302039 nosy: Oren Milman priority: normal severity: normal status: open title: ResourceWarning in Python/traceback.c in case of a bad io.TextIOWrapper type: resource usage versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31418] assertion failure in PyErr_WriteUnraisable() in case of an exception with a bad __module__
Oren Milman added the comment: what do you mean by 'Implicit converting to str can raise a warning or exception if __module__ is a bytes object.'? should we treat __module__ differently in case it is a bytes object? -- ___ Python tracker <https://bugs.python.org/issue31418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31418] assertion failure in PyErr_WriteUnraisable() in case of an exception with a bad __module__
Changes by Oren Milman : -- keywords: +patch pull_requests: +3534 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue31418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31471] assertion failure in subprocess.Popen() in case the env arg has a bad keys() method
New submission from Oren Milman: The following code causes an assertion failure on Windows: class BadEnv(dict): keys = None import subprocess import sys subprocess.Popen([sys.executable, "-c", "pass"], env=BadEnv()) this is because getenvironment() (in Modules/_winapi.c) calls PyMapping_Values() immediately after calling PyMapping_Keys(). calling PyMapping_Values() ultimately leads to calling _PyObject_FastCallDict(), which does 'assert(!PyErr_Occurred());'. thus, in case of an error in PyMapping_Keys(), the assertion fails. -- components: Extension Modules messages: 302181 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failure in subprocess.Popen() in case the env arg has a bad keys() method type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31471] assertion failure in subprocess.Popen() in case the env arg has a bad keys() method
Changes by Oren Milman : -- keywords: +patch pull_requests: +3570 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue31471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method
New submission from Oren Milman: The following code causes an assertion failure: class BadInt(int): def __abs__(self): return None import random random.seed(BadInt()) this is because random_seed() (in Modules/_randommodule.c) assumes that PyNumber_Absolute() returned an int, and so it passes it to _PyLong_NumBits(), which asserts it received an int. what should we do in such a case? should we raise an exception? (the docs don't mention abs() in case the seed is an int - https://docs.python.org/3.7/library/random.html#random.seed) -- components: Extension Modules messages: 302208 nosy: Oren Milman priority: normal severity: normal status: open title: assertion failure in random.seed() in case the seed argument has a bad __abs__() method type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue31478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31471] assertion failure in subprocess.Popen() in case the env arg has a bad keys() method
Oren Milman added the comment: in 2.7 getenvironment() is in PC/_subprocess.c, and it also calls PyMapping_Values() immediately after calling PyMapping_Keys(). however, _PyObject_FastCallDict() doesn't exist here. in case of an error in both PyMapping_Keys() and PyMapping_Values(), the error in PyMapping_Values() just overwrites the error in PyMapping_Keys(). but I haven't gone over all of the code that could be run as part of PyMapping_Values(), so I am not sure whether something could go wrong in case PyMapping_Keys() failed. -- ___ Python tracker <https://bugs.python.org/issue31471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31478] assertion failure in random.seed() in case the seed argument has a bad __abs__() method
Oren Milman added the comment: sure. but what about the TypeError message? should it complain about the return value of abs(seed)? (the docs of random.seed don't mention abs().) -- ___ Python tracker <https://bugs.python.org/issue31478> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31471] assertion failure in subprocess.Popen() in case the env arg has a bad keys() method
Oren Milman added the comment: OK. but there isn't an assertion failure to test in 2.7, so is adding a test still relevant? -- ___ Python tracker <https://bugs.python.org/issue31471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
