[Bug]: incorrect processing of '#' (alternate form) option for 'g' format type

[skirpichev]

Describe the bug

This was catched by mpmath test suite (https://github.com/mpmath/mpmath/actions/runs/29576666773/job/87873574671):

Python 3.12.8 (Tue Jun 23 15:26:01 UTC 2026)
[Graal, Oracle GraalVM, Java 25.0.3 (amd64)] on 'linux'
Type "help", "copyright", "credits" or "license" for more information.
>>> format(6.103515625e-05, '#.11g')
'6.103515625e-05'

vs

Python 3.12.13 (tags/v3.12.13:3bb231a6a5d, May 14 2026, 11:06:30) [GCC 14.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> format(6.103515625e-05, '#.11g')
'6.1035156250e-05'
>>> len('6.1035156250')-1
11

Per docs:

The precise rules are as follows: suppose that the result formatted with presentation type 'e' and precision p-1 would have exponent exp. Then, if m <= exp < p, where m is -4 for floats, the number is formatted with presentation type 'f' and precision p-1-exp. Otherwise, the number is formatted with presentation type 'e' and precision p-1. In both cases insignificant trailing zeros are removed from the significand, and the decimal point is also removed if there are no remaining digits following it, unless the '#' option is used.

It seems, '#' was incorrectly handled in some cases. Not always:

Python 3.12.8 (Tue Jun 23 15:26:01 UTC 2026)
[Graal, Oracle GraalVM, Java 25.0.3 (amd64)] on 'linux'
Type "help", "copyright", "credits" or "license" for more information.
>>> format(6.0e-5, '.11g')
'6e-05'
>>> format(6.0e-5, '#.11g')
'6.0000000000e-05'
>>> len('6.0000000000')
12

Operating system

Linux

CPU architecture

x86_64

GraalPy version

25.1.3

JDK version

No response

Context configuration

No response

Steps to reproduce

See description

Expected behavior

According Python docs

Stack trace

Additional context

No response