-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Future of eltypes #1596
Comments
We also have a more readable |
OK - so the decision is to deprecate |
Not sure. I know I was the one who wanted to kill it, but maybe it's fine to keep it. The main gripe with |
We can leave it as is for me, so I am OK, if you close this. Alternatively we could deprecate these names and add a preffix, e.g. Alternatively we could clearly document which functions work by columns and which by rows (most of the time this is pretty natural). |
I think In summary - I am closing this, but please reopen if you feel it needs more debate. |
That sentence isn't the most convincing argument. ;-) I've opened #1940 to see what changes the deprecation would imply. It's not too bad, so maybe we should merge it. As always, it's easier to reintroduce convenience functions if needed than the reverse. |
Well - it was a stream of thoughts :) rather than an argument |
More functions that do similar things = less readability, more confusion, and more to maintain. Esp. given |
Since now we can write
eltypes(df)
aseltype.(columns(df))
there is a question do we want to keepeltypes
function?The text was updated successfully, but these errors were encountered: