Panic on SchemaMismatch

[tkellogg]

Panic on SchemaMismatch

[deanm0000]

As an alternative

pl.concat([a, a.select(pl.lit(0).alias("a"))], how='vertical_relaxed')

does what you expect.

It makes sense to me that a python int would be treated the same between the different constructors. I'm not sure if there's a reason for the difference or it is just chance. @stinodego what do you think?

[tkellogg]

In addition, I wouldn't mind sending a patch for this. I would have, but I wanted to check first that it wasn't more complicated than it appeared. LMK

[stinodego]

A patch to turn the panic into a proper error is welcome!

It makes sense to me that a python int would be treated the same between the different constructors. I'm not sure if there's a reason for the difference or it is just chance. @stinodego what do you think?

There is a reason for the existing behavior, though off the top of my head I don't know why. Something to do with the difference between eager and lazy.

[tkellogg]

PR is ready to be reviewed. Pretty simple, I didn't try to address the inconsistent int handling.

@stinodego, if I were to guess, I bet the problem is that lazy Series can't infer a int32 without scanning it first, so it assumes int64. Whereas lit can trivially assume int64, and does. I'm not sure there's an easy way to fix this without breaking backward compatibility.

[ritchie46]

I didn't try to address the inconsistent int handling.

The lit int handling isn't something trivial. Literals should behave different from the constructor. They are dynamic and often need to depend on the operation to define their required type. E.g. multiply a int8 column with lit(1) should not upcast the int8 column.

If the lit is used in isolation, we try to fit a reasonably small dtype that fits. Currently that is int32. Smaller often leads to unexpected overflows. If the literal given doesn't fit int32 it is upcast to int64 or even uint64 if needed.

For the constructor we need to be more conservative as we don't want to inspect the whole array up front, whereas with a literal this is cheap, so we go with int64. If you need other behavior, you need to specify your dtype.

In a future version it might be possible that we recognize the dynamic literal usage across contexts and recognized that you were concatting to a i64, but this isn't trivial and I think also not worth the compute cost.