Rebased. PTAL

CScalar is another representation of a scalar. I think it's not that unnatural to hold numpy_value internally.

Simplicity of the code that uses it, rather than its internal structure, is more important IMO.

In my understanding, the PR assumes that _preprocess_args must convert scalars into both numpy scalars and c scalars anyway.

What do you mean?
With this PR, scalars are always converted to CScalar, not NumPy scalars.

CScalar is another representation of a scalar. I think it's not that unnatural to hold numpy_value internally.

Simplicity of the code that uses it, rather than its internal structure, is more important IMO.

Then the name CScalar is not appropriate for its complexity. Please rename it to something like CScalarPossiblyWithNumpyScalar or ScalarCachesForKernel and move the class to a suitable file. Maybe it's better to define a new class with attributes to hold an old CScalar and a NumPy scalar object.

What do you mean?
With this PR, scalars are always converted to CScalar, not NumPy scalars.

I mean the PR comment sounds like that it avoids the conversion to NumPy scalars. However the new implementation forces the conversion (in the sense that a new CScalar object has a NumPy scalar (if created by _scalar.scalar_to_c_scalar)).

Although I agree CScalar is not an appropriate name because it does not represent a "C" scalar (as I understand), I don't understand why it would have to include its internal structure in its name (...PossiblyWithNumpyScalar). I don't understand the meaning of ...CachesForKernel either.
Also, why do you think _scalar.pyx is not a suitable place?

Maybe it's better to define a new class with attributes to hold an old CScalar and a NumPy scalar object.

What would be the semantic difference between the new class and CScalar?
Maybe I don't understand the role of CScalar. It would be nice to clarify it first.

I mean the PR comment sounds like that it avoids the conversion to NumPy scalars.

No, I didn't mean that at all.
I presume all the scalars are eventually converted to NumPy anyway even before this PR.
I don't yet understand the whole code, so I might have a misunderstanding here, too.

I presume all the scalars are eventually converted to NumPy anyway even before this PR.

I agree.

role of CScalar

By CScalar.from_int32, I guess the old CScalar class (just the union Scalar with allocation) has another reason to exist. Keeping it makes sense to me.

another reason

That's exactly what I want to clarify. I'm beginning to feel you are correct, but I want to make it explicit.

Maybe it's corresponding to a "C" scalar as the name suggests? But then I don't understand why it has to be created in _preprocess_args...

Please give me some time to think.

The team decided that this change will be discussed along with other refactoring PRs.