Niels Bantilan

Agreed on copying the Column (I don't think the cost of copying would be high) I think for this issue, let's do the following: - Change [`Column.set_name`](https://github.com/pandera-dev/pandera/blob/master/pandera/schema_components.py#L129-L136) so that it...

@Anders-E @NickCrews do either of you want to make a PR for ^^?

> That change to Column.set_name would be breaking for users would it? how?

thanks @NickCrews ! I'm not super concerned that `Column.set_name` will be a breaking change... as you and @Anders-E pointed out, in-plce mutation of the Column when it's fed into a...

I not _super_ concerned that this will have a big impact, since I'm not sure how many people using `Column`s by themselves rely on the fact that it's mutated in...

gotcha, agreed, so let's do what I mentioned in https://github.com/pandera-dev/pandera/issues/511#issuecomment-1119620703: > to be safe let's manually to a copy.deepcopy of the Column before calling set_name here: https://github.com/pandera-dev/pandera/blob/master/pandera/schemas.py#L282-L289

Hi @Fransisnk this use case makes sense! Welcoming PRs to fulfill this use case, adding the _help wanted_ tag

I believe coercion only happens once... the `DataFrameSchema.coerce_dtype` calls `Column.coerce_dtype` [here](https://github.com/pandera-dev/pandera/blob/master/pandera/schemas.py#L387-L406). The behavior you're seeing is actually intended behavior given pandera's current execution model. In summary, if a column cannot...

> I believe coercion only happens once okay so it looks like coercion does happen twice 😅 this is definitely a bug... will look into correcting that. Re: the execution...

Hi @PezAmaury a built-in way to do conditional checks at the column-level would for sure be useful, let's keep this issue open because I have a few ideas on how...