-
Of course you're right, the spec does say inputs shouldn't be rounded. And that last example is horrendous: sqrt should definitely be monotonic (a floating function f is "monotonic" if it guarantees f(x) >= f(y) whenever x >= y; you found x and y such that x > y but sqrt(x) < sqrt(y) -- ouch!).
2007-06-22 16:06:49 UTC in Python
-
Doesn't the spec also require that /inputs/ get rounded to working precision /before/ operations are performed? If so, the exact square 83237431137025 is rounded down to 83237400000000, and sqrt(83237400000000) is 9.12345E+6 rounded to 6 digits.
2007-05-25 23:24:37 UTC in Python
-
There is no such rule, and it's quite deliberate that the newer types (like datetime objects and sets) raise an exception on mixed-type inequality comparisons. For older types, the result of inequality comparison with None isn't defined by the language, and the outcome does vary across CPython releases.
Rejecting this, since the code is working as designed and documented (see, e.g., footnote...
2007-03-04 18:48:14 UTC in Python
-
Since the top 6 or 7 stack entries are all in /usr/lib/mysql/libmysqlclient_r.so.14, and shows it trying to using its own free() function (my_no_flags_free()), it's almost certainly a problem in the extension module (as opposed to in Python).
2007-02-06 10:31:18 UTC in Python
-
Very nice! I'd add a description of the minor pathology remaining you described here as a code comment, at the point is_tripped is set to 0. If this stuff were screamingly obvious, the bug you fixed wouldn't have persisted for 15 years ;-)
2007-01-24 20:19:33 UTC in Python
-
The statement that the various ways of extracting info from a dict are consistent /provided that/ they're "called with no intervening modifications to the dictionary" (did you miss that crucial qualification?) is part of the language definition: it definitely and deliberately constrains the set of possible implementations.
The docs didn't originally say this, but people noted it was true in...
2006-12-09 14:51:48 UTC in Python
-
The docs are written from the POV that indices in Python point /between/ array elements, which is the easiest way to understand slices, and that there are n+1 non-negative indices that "make obvious sense" in slices of a sequence with n elements: index 0 points "just before" element a[0], and index n "just after" element a[n-1], while for 0 < i < n-1, index i points "just before" element [i]...
2006-11-24 19:16:05 UTC in Python
-
Logged In: YES
user_id=31435
> I tried Tim's hope.py on Linux x86_64 and
> Mac OS X 10.4 with debug builds and neither
> one crashed. Tim's guess looks pretty damn
> good too.
Neal, note that it's the /Windows/ malloc that fills freed
memory with "dangerous bytes" in a debug build -- this
really has nothing to do with that it's a debug build of
/Python/ apart from that on Windows a...
2006-10-28 05:18:13 UTC in Python
-
Logged In: YES
user_id=31435
I've attached a much simplified pure-Python script (hope.py)
that reproduces a problem very quickly, on Windows, in a
/debug/ build of current trunk. It typically prints:
exiting generator
joined thread
at most twice before crapping out. At the time, the `next`
argument to newtracebackobject() is 0xdddddddd, and tracing
back a level shows that, in...
2006-10-19 00:38:53 UTC in Python
-
Logged In: YES
user_id=31435
> Can anybody tell why gi_frame *isn't* incref'ed when
> the generator is created?
As documented (in concrete.tex), PyGen_New(f) steals a
reference to the frame passed to it. Its only call site
(well, in the core) is in ceval.c, which returns immediately
after PyGen_New takes over ownership of the frame the caller
created:
"""
/* Create a new generator...
2006-10-18 21:57:22 UTC in Python
