I came to the same solution.

The simple test can be based on the #118027 example.

But the case of xc exactly equal to 10**p is not currently covered by tests. So you can remove _is_power_of_10, and the tests will still pass. How difficult is to write a test for this case?

EDIT: never mind. I still don't understand how _pydecimal gets tested at all (if it in fact does), but I did find a simple way to force test_decimal.py to try the simple test described below using _pydecimal.py.

I don't know anything about how to write tests for _pydecimal, and after too many minutes of staring at test_decimcal.py couldn't even figure out how (or if) it gets tested at all.

@rhettinger, is this shallow to you? I need help to get started. I'd like to add a test that sets the context Emax to decimal.MAX_EMAX, and then evaluates decimal.Decimal(2) ** 117. That's it. But it has to be tried under _pydecimal.py (where it currently appears to hang, while computing 10**MAX_EMAX).

But the case of xc exactly equal to 10**p is not currently covered ... How difficult is to write a test for this case?

No idea. xc at this point has been transformed from what it was at input, and so far nobody seems to know what its possible range may be at this point in the code (nor at the other point where 10**p is computed) . Neither how to contrive an input that ends up with xc being large at these points. Any input xc that's an integer power of 10 >= 1 was handled long before reaching these points.

A smidgen of progress: in the first block that tests whether xc > 10**p, xc was transformed to be one of 2**e or 5**e. Neither can be a power of 10 (unless e is 0), so only len(str(xs)) <= p is possibly relevant.

And another smidgen: in the other block, xc ix changed to xc**m. That could be very large on its own, but the code doing that - before doing that - does a fast check using a lower bound on log10(xc) which weeds out results materially larger than 10**p. So our str(xc) in this block can at worst only have a few more than p digits. Checking it against 10**p exactly before converting to string wasn't really important, but faster in "too large!" cases. Which never happen when p is in the quintillions 😉

After the comment here:

        # if m > p*100//_log10_lb(xc) then m > p/log10(xc), hence xc**m >
        # 10**p and the result is not representable.
        if xc > 1 and m > p*100//_log10_lb(xc):
            return None

I inserted:

        assert xc != 1, self
        assert not _is_power_of_10(str(xc)), self

The second assert is more general. No code I have triggers them (including test_decimal), and I haven't been able to contrive inputs that trigger them.

So I've so far failed to falsify my original guess that, near the end of this code, xc is never a power of 10. In which case, xc**m can never be a power of 10 either, so that in the original xc > 10**p, xc == 10**p isn't possible.

Yet the code guards against xc == 1 anyway. For example, in the code quoted above, xc > 1 and ..., best I can tell xc > 1 is always true (for other reasons xc cannot be <= 0).

If so, doesn't mean there's a bug, just that the code is being a tiny bit more cautious than necessary. For example, perhaps this code was written before the much earlier code in the function that special-cases the snot out of inputs where xc is a power of 10 >= 1 (and it's because of that code that I first believed all such cases were probably handled in full early on).

Also if so, str(xc) > p alone is both necessary and sufficient for this function to return None. The case of a 1 followed by p (or any other number of) zeros can't happen in the two code blocks at issue.

Thanks @tim-one for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12.
🐍🍒⛏🤖

GH-118584 is a backport of this pull request to the 3.12 branch.

I think that this was a bug, and this change should be backported.

@serhiy-storchaka, backporting is a fine idea. I'll leave it to you 😄.