Describe the issue:

Notable behavior with Python builtin type classes acknowledges the difference between using result_type with Python scalar values (e.g. 1) vs Python scalar types (e.g. int) and explains "why" at a surface level:

The reason for this behavior is that NumPy converts int its default integer type, and uses that type for promotion

But why does it have to behave that way?

If result_type is supposed to predict the result of an operation between values of the provided types/dtypes,

import numpy as np
np.result_type(np.int32(1), int(1))  # dtype('int32')
np.result_type(np.int32, int)  # dtype('int64')
np.result_type(np.float32(1), float(1))  # dtype('float32')
np.result_type(np.float32, float)  # dtype('float64')

seems incorrect.

I'd speculate that the behavior is just an accidental holdout from pre-NEP 50 promotion rules, since before that, both:

np.result_type(xp.asarray(1), float)  # dtype('float64')
np.result_type(np.asarray(1), 1.0)  # dtype('float64')

so the behaviors should have both changed at that time.

As such, I think there's still time to label it a bug to be fixed, not a feature.

Crossref #29821 (comment)

Reproduce the code example:

import numpy as np
np.result_type(np.int32(1), int(1))  # dtype('int32')
np.result_type(np.int32, int)  # dtype('int64')
np.result_type(np.float32(1), float(1))  # dtype('float32')
np.result_type(np.float32, float)  # dtype('float64')

Error message:

NA

Python and NumPy Versions:

2.4.0
3.12.13 (main, Mar 4 2026, 09:23:07) [GCC 11.4.0]

Runtime Environment:

[{'numpy_version': '2.4.0',
  'python': '3.12.13 (main, Mar  4 2026, 09:23:07) [GCC 11.4.0]',
  'uname': uname_result(system='Linux', node='c3928b788805', release='6.6.113+', version='#1 SMP Mon Feb  2 12:27:57 UTC 2026', machine='x86_64')},
 {'simd_extensions': {'baseline': ['X86_V2'],
                      'found': ['X86_V3'],
                      'not_found': ['X86_V4', 'AVX512_ICL', 'AVX512_SPR']}},
 {'ignore_floating_point_errors_in_matmul': False},
 {'architecture': 'Haswell',
  'filepath': '/usr/local/lib/python3.12/dist-packages/numpy.libs/libscipy_openblas64_-fdde5778.so',
  'internal_api': 'openblas',
  'num_threads': 2,
  'prefix': 'libscipy_openblas',
  'threading_layer': 'pthreads',
  'user_api': 'blas',
  'version': '0.3.30'}]

How does this issue affect you or how did you find it:

Like gh-31019 - testing a library that leverages mpmath and NumPy object arrays to implement an array API standard compatible, arbitrary precision array.