Using `constructor.name` for `dataType.variant` seems not to be reliable

[roll]

Have you tried latest version of polars?

• [yes]

What version of polars are you using?

0.21.2

What operating system are you using polars on?

Ubuntu 24

What node version are you using

Node 24

Describe your bug.

I ran into weird bug when type inference based on DataFrame logic didn't match between running my project in Node and in Bun-compiled binary. After digging in a little bit a found out that the datatype.variant differs in builds (which broke the following login in the function):

polarsField: { name: 'name', type: DataType(String) },

polarsField: { name: 'name', type: DataType(String2) },

It's X layers of indirection (builds/compilers/etc) to figure out why it acts like this so I guess a safer solution would be just using constant for type identities to eliminate this possibility

[Bidek56]

Do you think this is Bun vs. Node issue or nodejs-polars issue? Can you please elaborate on your fix? Thx

[roll]

I think it might be unsafe to use return this.constructor.name as DataTypeName; as different tools can approach source code differently e.g. minifying class names String -> s. To eliminate this possibility I would suggest just using explicit variants something like:

export class Categorical extends DataType<"Categorical"> {
  variant = 'Categorical'
}

[Bidek56]

We already have this definition:

export class Categorical extends DataType<"Categorical"> {
  declare __dtype: "Categorical";
}

Would you be willing to put a PR in? Thx

[roll]

Sure, thanks, I will pr