Which use-case in particular do you have in mind ? I had the impression that between 30b it+sign or 28 bit + sign it would not make a big difference: It is anyway not enough to avoid switching to bigger ints when dealing with 32bit external interfaces, , but it is large enough to deal with everyday numbers

1. It's a breaking change. One simply does not know how much code relies on small INTs being 31 bits. This is not only a matter of number range, but also of allocations and runtime.
2. I do not know what you call everyday numbers.
3. Some ports + boards do not support float. The will loose the larger range without any benefit.
4. The application for floats I see usually deal anyhow with imprecise data. Thus getting two more low order bits usually does not improve things. If you want to do high precision number crunching, use a suitable board or machine.

I think there is a misunderstanding: the intent is not to change the size of smallints for all of MicroPython, the scope is only one specific OBJ_REPR model.

1. Using 28+1 bits as smallints does no cause a major issue with MicroPython core. The size of smallints MicroPython core is already fully parametric.

• OBJ_REPR_A uses 30+1 bits
• OBJ_REPR_B uses 29+1 bits
• OBJ_REPR_C uses 30+1 bits
• OBJ_REPR_D uses 46+1 bits
  The only problem I can foresee is that mpy files produced by mpycross are typically compiled for 30+1 bit smallints, unless a different size is specified at compile time. If someone would distribute such mpy files, which would currently work only with REPR_A and REPR_C, they would not work anymore with REPR_C. Hence my suggestion to make this a new REPR than changing REPR_C.

2. By everyday numbers I mean sizes, durations, counts, typically used in an embedded applications, in particular those that I care about in my job (small automation based on sensors and actuators).

3. REPR_C already has a requirement to have floats enabled. Nobody would choose REPR_C without using floats.

4. I have disagree here. If this discussion was about double-precision floats, I would not care. But with single-precision floats, loosing two bits instead of one at every intermediate result of a computation makes a visible difference at the end.

CircuitPython uses OBJ_REPR_C for all its 32-bit ports. Our original port to SAMD21 was on a RAM-starved processor, so we didn't opt for boxed floats. Please do not change OBJ_REPR_C, as our library code, and some internal code, is cognizant of that choice. We don't care if you make an OBJ_REPR_E, but I'm not sure who would use it.

ulab uses mp_float_t internally, which is float, so full 32-bit float arithmetic is available, though I don't know if anyone taken advantage of that to improve the accuracy of some calculation.