Un-deprecate DataFrame.from_items()

[jzwinck]

Under #18262 a FutureWarning was added suggesting that existing code like this:

pd.DataFrame.from_items(x)

Should be changed to this:

import collections
pd.DataFrame.from_dict(collections.OrderedDict(x))

The fact that from_items() appeared only 6 times (now 8 times) in a Stack Overflow search was used as partial justification for removing it. But if you search on GitHub, pd.DataFrame.from_items() appears more than 15,000 times in Python--almost half as many as from_records()!

We should celebrate the fact that this function doesn't cause enough confusion to appear often on Stack Overflow. But it does occur (a lot!) in real code, and deprecating it is a mistake.

If constructing a temporary OrderedDict around items is the best way to construct a DataFrame, Pandas should implement that as a short function called DataFrame.from_items(), rather than asking thousands of people to busy themselves to accommodate this unnecessary API change.

I recommend removing the FutureWarning, and retaining this widely-used, longstanding function.

For reference, the FutureWarning starts in 0.23 and looks like this:

FutureWarning: from_items is deprecated. Please use DataFrame.from_dict(dict(items), ...) instead. DataFrame.from_dict(OrderedDict(items)) may be used to preserve the key order.

[gfyoung]

cc @jreback @chris-b1

[jzwinck]

@jreback I would appreciate your review of this topic.

[jorisvandenbossche]

cc @reidy-p @chris-b1

[jreback]

I disgree, this is a good deprecation. Keeping around old code is not helpful. So -1 on adding back.

[jzwinck]

@jreback It is clear that you think this is a good deprecation, otherwise you would not have done it. However, the initial justification ("only 6 hits on Stack Overflow") completely ignored the larger picture, which is that this function is widely used in a huge number of applications and libraries.

It might be the case that the original implementation was unwieldy or costly to maintain. But what could be the reason not to maintain backward compatibility by a 3-line function that delegates the work to OrderedDict and the main DataFrame constructor?

In other words, maybe the old code was not helpful. Would you accept new code to implement this widely-used function in a single place, rather than having thousands of users sprinkle the same into their local codebases?

[jreback]

there is a burden to maintain apis and code
why should this be any different from other ‘highly used code’

[jorisvandenbossche]

I agree with @jzwinck that "old code" and "burden to maintain apis and code" is not a good reason for deprecating from_items. from_items is really not that of a complicated function (compared to many other things in pandas) and as @jzwinck shows can be easily cleaned-up.

If that was the original reason to deprecate it, I think the PR of @jzwinck is a perfectly reasonable solution.

However, often when we deprecate one of the public methods, the main reasons are related to the "User API" design: inconsistent apis, duplicate functionality, hardly useful functionality that clobbers the API, etc are all reasons to consider deprecating a functionality.
We have a huge number of methods on the DataFrame object, and this huge number results in an overload for users. Therefore for having something as a method on the DataFrame, there should be a clear added value that is big enough to balance the added complexity / API load.

So also for from_items: is it worth having this as a DataFrame method given the relatively limited use case / relatively easy alternative?

And to be clear, such a trade-off is difficult and subjective.
And when it is about removing existing functionality (instead of adding a new method), the balance should typically be more strongly against having the method (because then there is also the disruption of the existing use cases).

---

That said, I personally never had a use case myself where from_items would have been fitting. That is not saying that those do not exist, but for me it is very hard to judge its usefulness.

If this would have been a new method proposal, I would probably be -1 to add it. But given that this is about removing an already existing method, I personally don't know.