[issue38629] float is missing __ceil__() and __floor__(), required by numbers.Real
New submission from Ran Benita : The numbers.Real ABC requires the __ceil__ and __floor__ methods (https://github.com/python/cpython/blob/v3.8.0/Lib/numbers.py#L178-L186), however, the float type does not have them. In regular Python, this is not a problem, because math.ceil() and math.floor() special-case float and work on it directly, and numbers.Real is implemented on float by explicitly registering it (so it's not checked that all required methods are implemented). Where it becomes a (minor) problem is in typeshed, where the type checker *does* check that all abstract methods are implemented. So, because float is missing these two, typeshed cannot have float implement numbers.Real. Refs: https://github.com/python/typeshed/issues/3195 -- components: Interpreter Core, Library (Lib) messages: 355642 nosy: bluetech priority: normal severity: normal status: open title: float is missing __ceil__() and __floor__(), required by numbers.Real type: behavior ___ Python tracker <https://bugs.python.org/issue38629> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38629] float is missing __ceil__() and __floor__(), required by numbers.Real
Ran Benita added the comment: You can take it - thanks! -- ___ Python tracker <https://bugs.python.org/issue38629> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42588] Improvements to graphlib.TopologicalSorter.static_order() documentation
New submission from Ran Benita : One issue and one suggestion. Issue: The documentation of prepare() says: > If any cycle is detected, CycleError will be raised which is what happens. The documentation of static_order() says that static_order() is equivalent to: def static_order(self): self.prepare() while self.is_active(): node_group = self.get_ready() yield from node_group self.done(*node_group) specifically it is said to call self.prepare(), and also says > If any cycle is detected, CycleError will be raised. But, this only happens when the result of static_order is *iterated*, not when it's called, unlike what is suggested by the code and the comment. Ideally, I think the call should raise the CycleError already if possible; this way, only the call can be wrapped in a try/except instead of the entire iteration. But if not, it should be clarified in the documentation. Suggestion: The documentation of static_order() says > Returns an iterable of nodes in a topological order. Using this method does > not require to call TopologicalSorter.prepare() or TopologicalSorter.done(). I think the wording "does not require" still implies that they *can* be called, but really they can't. If prepare() is called before static_order(), then when static_order() is iterated, "ValueError: cannot prepare() more than once" is raised. I suggest this wording: Returns an iterable of nodes in a topological order. When using this method, TopologicalSorter.prepare() and TopologicalSorter.done() should not be called. -- assignee: docs@python components: Documentation messages: 382647 nosy: bluetech, docs@python priority: normal severity: normal status: open title: Improvements to graphlib.TopologicalSorter.static_order() documentation versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42588] Improvements to graphlib.TopologicalSorter.static_order() documentation
Ran Benita added the comment: Hmm I realize after the fact that since the equivalent code snippet (which is actually the implementation) is a generator, then it is actually correct that prepare() isn't called until it is iterated. So the documentation for this is not incorrect. Still, I think it would be better if the prepare() executes immediately rather than in the first iteration. -- ___ Python tracker <https://bugs.python.org/issue42588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41909] Segfault on __getattr__ infinite recursion on certain attribute accesses
New submission from Ran Benita :
The following program crashes with a segfault:
class Segfault:
def __getattr__(self, name):
self.unknown_attribute
instance = Segfault()
issubclass(instance, int) # int doesn't matter
Tested with Python 3.7, 3.8, 3.9rc2, and master in debug mode (commit
497126f7ea955ee005e78f2cdd61f175d4fcdbb2).
The program is odd, but this affects pytest (see
https://github.com/pytest-dev/pytest/issues/2330).
The class is buggy user code, pytest does the issubclass check.
In pytest there are other code paths which trigger it besides issubclass, but
that's the one I am able to quickly reproduce standalone.
Here is the backtrace with python master:
ran@ran:~/src/cpython$ gdb --args ./python segfault.py
Reading symbols from ./python...
(gdb) r
Starting program: /home/ran/src/cpython/python segfault.py
Program received signal SIGSEGV, Segmentation fault.
0x556bc55e in PyGILState_Check () at Python/pystate.c:1353
1353if (!PyThread_tss_is_created(&gilstate->autoTSSkey)) {
(gdb) bt 29
#0 0x556bc55e in PyGILState_Check () at Python/pystate.c:1353
#1 0x555fc117 in _PyMem_DebugCheckGIL (func=0x5581b330
<__func__.10> "_PyMem_DebugMalloc") at Objects/obmalloc.c:2329
#2 _PyMem_DebugMalloc (ctx=0x5593b140 <_PyMem_Debug+96>, nbytes=185) at
Objects/obmalloc.c:2329
#3 0x555fcee8 in PyObject_Malloc (size=) at
Objects/obmalloc.c:685
#4 0x5562d6f3 in PyUnicode_New (size=136, maxchar=) at
Objects/unicodeobject.c:1455
#5 0x556556e7 in _PyUnicodeWriter_PrepareInternal
(writer=writer@entry=0x7f7ff0c0, length=length@entry=1, maxchar=, maxchar@entry=127)
at Objects/unicodeobject.c:14004
#6 0x55658439 in _PyUnicodeWriter_WriteASCIIString
(writer=writer@entry=0x7f7ff0c0, ascii=ascii@entry=0x558196c8 "'%.50s'
object has no attribute '%U'",
len=1) at Objects/unicodeobject.c:14174
#7 0x5565a18d in PyUnicode_FromFormatV
(format=format@entry=0x558196c8 "'%.50s' object has no attribute '%U'",
vargs=vargs@entry=0x7f7ff170)
at Objects/unicodeobject.c:3114
#8 0x5569646b in _PyErr_FormatV (tstate=0x559aa300,
exception=,
format=format@entry=0x558196c8 "'%.50s' object has no attribute '%U'",
vargs=vargs@entry=0x7f7ff170) at Python/errors.c:1029
#9 0x55696ff3 in PyErr_Format (exception=,
format=format@entry=0x558196c8 "'%.50s' object has no attribute '%U'") at
Python/errors.c:1071
#10 0x555fa4a5 in _PyObject_GenericGetAttrWithDict
(obj=obj@entry=,
name=name@entry='unknown_attribute', dict=,
dict@entry=0x0, suppress=suppress@entry=0) at Objects/object.c:1268
#11 0x555fa96f in PyObject_GenericGetAttr (obj=obj@entry=, name=name@entry='unknown_attribute') at
Objects/object.c:1281
#12 0x5561c3f8 in slot_tp_getattr_hook (self=, name='unknown_attribute') at Objects/typeobject.c:6805
#13 0x555f68c2 in PyObject_GetAttr (v=v@entry=, name=) at Objects/object.c:891
#14 0x5567c254 in _PyEval_EvalFrameDefault (tstate=0x559aa300,
f=Frame 0x771cc3b0, for file /home/ran/src/cpython/segfault.py, line 3,
in __getattr__ (self=,
name='unknown_attribute'),
throwflag=) at Python/ceval.c:3036
#15 0x555b9d1d in _PyEval_EvalFrame (throwflag=0,
f=Frame 0x771cc3b0, for file /home/ran/src/cpython/segfault.py, line 3,
in __getattr__ (self=,
name='unknown_attribute'),
tstate=0x559aa300) at ./Include/internal/pycore_ceval.h:40
#16 function_code_fastcall (tstate=0x559aa300, co=,
args=0x7f7ff590, nargs=2, globals=) at Objects/call.c:329
#17 0x555ba67b in _PyFunction_Vectorcall (func=,
stack=, nargsf=, kwnames=) at
Objects/call.c:366
#18 0x5576c2d4 in _PyObject_VectorcallTstate (tstate=0x559aa300,
callable=, args=0x7f7ff580, nargsf=2,
kwnames=0x0)
at ./Include/cpython/abstract.h:114
#19 0x5576cb87 in method_vectorcall (method=,
args=0x7f7ff588, nargsf=, kwnames=0x0) at
Objects/classobject.c:53
#20 0x556109ac in _PyObject_VectorcallTstate (kwnames=0x0,
nargsf=9223372036854775809, args=0x7f7ff588, callable=,
tstate=0x559aa300) at ./Include/cpython/abstract.h:114
#21 PyObject_CallOneArg (arg='unknown_attribute', func=) at ./Include/cpython/abstract.h:184
#22 call_attribute (self=self@entry=,
attr=, attr@entry=,
name=name@entry='unknown_attribute') at Objects/typeobject.c:6771
#23 0x5561c44a in slot_tp_getattr_hook (self=, name='unknown_attribute') at Objects/typeobject.c:6813
#24 0x555f68c2 in PyObject_GetAttr (v=v@entry=, name=) at Objects/object.c:891
#25 0x5567c254 in _PyEval_EvalFrameDefault (tstate=0x559aa300,
[issue41909] Segfault on __getattr__ infinite recursion on certain attribute accesses
Change by Ran Benita : -- type: -> crash ___ Python tracker <https://bugs.python.org/issue41909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
