abs(-0.0) returns -0.0 instead of 0.0, and math.fabs(-0.0) does the
same. Both come from the idiom (x < 0) ? -x : x. Since -0.0 < 0 is
false, the negative zero is returned unchanged.
The idiom appears twice, once in dmath_fabs and once open-coded in
float__abs__. Fix dmath_fabs by clearing the sign bit, the same way
dmath_copysign just above it works, and make float__abs__ call the
shared helper instead of repeating the comparison.
abs(-0.0) == 0.0 is true even with the bug, because -0.0 == 0.0 under
IEEE 754, so the added tests compare str(...) to check the sign.
zfill writes the padding zeros before the whole string, so a leading
+ or - ends up in the middle of the result instead of staying in front.
For example "-5".zfill(4) gave '00-5' where CPython gives '-005'.
CPython inserts the padding after the sign character, and the sign
counts toward the requested width. Write the sign first, then the
zeros, then the rest of the string. delta is still computed before
this, so the total length is unchanged.
The existing tests only covered unsigned strings, which is why this
went unnoticed. Added three asserts alongside them.
Adds an optional open_file callback to py_Callbacks, consulted before
script-reachable file operations:
- io.FileIO(path, mode): called with the fopen mode string before the open
- os.remove(path): called with the literal "delete"
Returning false rejects the operation and raises OSError; returning true
(or leaving the callback NULL, which is the default) allows it. Existing
embedders are unaffected -- the default is NULL and behavior is unchanged.
This lets an embedder enforce its own path policy using its own
canonicalization instead of reimplementing path checks inside the VM.
The pocketpy extension for orx has been merged upstream and is included with the engine out of the box, so my fork is no longer required to use pocketpy + orx.
* Initial plan
* docs: add contributing guide and link from README
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
