Future of eltypes

[bkamins]

Since now we can write eltypes(df) as eltype.(columns(df)) there is a question do we want to keep eltypes function?

[pdeffebach]

We also have a more readable describe for getting a quick picture of a DataFrame, including its eltypes, which is what I imagine this is mostly being used for. So I vote to drop it.

[bkamins]

OK - so the decision is to deprecate eltypes?

[nalimilan]

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 eltypes is that it's column-oriented while we've decided functions should operate on rows by default (#1514), but there are other functions like this that we won't deprecate (names, describe, allowmissing!, categorical!...).

[bkamins]

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. col, to all of them. But I am not sure if it is worth it, so I did not even propose it later.

Alternatively we could clearly document which functions work by columns and which by rows (most of the time this is pretty natural).

[bkamins]

I think eltypes is hardly used nowdays, but it does not hurt so maybe let us keep it.

In summary - I am closing this, but please reopen if you feel it needs more debate.

[nalimilan]

I think eltypes is hardly used nowdays, but it does not hurt so maybe let us keep it.

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.

[bkamins]

Well - it was a stream of thoughts :) rather than an argument

[kescobo]

More functions that do similar things = less readability, more confusion, and more to maintain. Esp. given describe(), and the ability to broadcast eltype() on columns, I think removing it makes a lot of sense.