Optionally pass type to Column
#78
Assignees
Labels
Comments
lars-reimann
added a commit
that referenced
this issue
Mar 25, 2023
Closes #78. ### Summary of Changes For the sake of consistency it is now possible to pass the type of a `Column` in the constructor. This also improves performance, for example when we call `get_column` on a `Table`. In that case we already know the type of the column anyway, so there's no reason to infer it again. --------- Co-authored-by: lars-reimann <[email protected]>
lars-reimann
pushed a commit
that referenced
this issue
Mar 26, 2023
## [0.4.0](v0.3.0...v0.4.0) (2023-03-26) ### Features * better names for properties of `TaggedTable` ([#74](#74)) ([fee398b](fee398b)) * change the name of a `Column` ([#76](#76)) ([ec539eb](ec539eb)) * metrics as methods of models ([#77](#77)) ([bc63693](bc63693)), closes [#64](#64) * optionally pass type to column ([#79](#79)) ([64aa429](64aa429)), closes [#78](#78) * remove `target_name` parameter of `predict` ([#70](#70)) ([b513454](b513454)), closes [#9](#9) * rename `tagged_table` parameter of `fit` to `training_set` ([#71](#71)) ([8655521](8655521)) * return `TaggedTable` from `predict` ([#73](#73)) ([5d5f5a6](5d5f5a6))
|
🎉 This issue has been resolved in version 0.4.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem?
For
Tables we can optionally pass a schema. ForColumns the type is always inferred. This is not consistent.Desired solution
Add an optional parameter to the
Columnconstructor for the type of theColumn. If it's passed, we accept it. Otherwise, we infer the type as before.Possible alternatives (optional)
No response
Screenshots (optional)
No response
Additional Context (optional)
No response
The text was updated successfully, but these errors were encountered: