New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
py3: strange behavior of sleep() on Sage types #26311
Comments
This comment has been minimized.
This comment has been minimized.
comment:2
Thanks for the investigation. |
comment:4
Retargeting some of my tickets (somewhat optimistically for now). |
Upstream: Reported upstream. No feedback yet. |
This comment has been minimized.
This comment has been minimized.
comment:6
It feels like there's been a bad habit in CPython lately of needlessly breaking support for custom numerical types. |
Changed upstream from Reported upstream. No feedback yet. to Reported upstream. Developers acknowledge bug. |
comment:8
Yeesh, that thread on bpo is a mess... :( |
This comment has been minimized.
This comment has been minimized.
comment:9
Replying to @embray:
Wait until you see the code. DRY clearly does not apply to the CPython code base: I had to make the same fix 3 times. |
comment:11
Removing most of the rest of my open tickets out of the 8.7 milestone, which should be closed. |
comment:12
Replying to @jdemeyer:
For this ticket 1 time is enough, solved with two line patch: --- a/Python/pytime.c
+++ b/Python/pytime.c
@@ -404,9 +404,11 @@
}
static int
-_PyTime_FromObject(_PyTime_t *t, PyObject *obj, _PyTime_round_t round,
+_PyTime_FromObject(_PyTime_t *t, PyObject *xobj, _PyTime_round_t round,
long unit_to_ns)
{
+ PyObject *obj;
+ obj = PyNumber_Float(xobj);
if (PyFloat_Check(obj)) {
double d;
d = PyFloat_AsDouble(obj); This patch solves only one thing:
and only for I understand that custom builded python is not for everyone. |
For some reason, passing Python's
time.sleep()
a SageRealLiteral
less than 1 returns more-or-less immediately:It's not just in the context of
timeit
either. 0.5 is long enough that if you dosleep(x2)
directly you can feel the delay, whereas withsleep(x)
there is much less or even no perceptible delay.''However,
as expected.
The problem appears to stem from the (relatively) new PyTime API, and in particular this function:
So it does not properly handle custom types that implement
__float__
.Reported upstream:
In the meantime I don't see that there's much to be done except to always wrap Sage types in
float()
before passing them to time functions (or, more extreme, provide our own wrappers for common time functions...)Upstream: Reported upstream. Developers acknowledge bug.
Component: python3
Issue created by migration from https://trac.sagemath.org/ticket/26311
The text was updated successfully, but these errors were encountered: