Maybe pandas.DataFrame.from_series(cls, data, orient='columns', dtype=None)?

data = list of pandas.Series.

Order is set inherently and column names or index values (depending on orient) can be extracted from the series (or set to default values when not available)

lines up with;

• pandas.DataFrame.from_csv
• pandas.DataFrame.from_dict
• pandas.DataFrame.from_records

I am not a big fan off one does it all __init__.

Sure, @lodagro; alternate factory functions/consturctors would be just fine, and are indeed a cleaner alternative to making over-complicated __init__ methods that try to read your mind.

I think it makes sense to have a constructor that takes the form that Fernando describes, since it's sort of a "dict-like" interface to begin with. At the moment the constructor will accept

• 2D ndarray optional index/columns
• structured ndarray index or columns
• dict index or columns
• Lists, which are treated as ndarrays

maybe the method should be called like

DataFrame.from_items

to be analogous with dict.(iter)items and friends-- sounds good? And adding an orient parameter will be pretty simple

Incidentally I half wish that I hadn't called the Panel field names items

Sorry, what would orient be used for?

Suppose that you intend for the keys to be the row labels instead of the column labels-- but you also want to infer the right dtype for the columns. If you did

df = DataFrame.from_items(items).T

to achieve that, but the values are, say, lists with mixed types-- the resulting DataFrame would currently come out as all dtype=object. orient='index' would save you from that

analogous functionality is available in DataFrame.from_dict because it's quite common that you will convert a nested dict to DataFrame, before the orient parameter it was common to lose the dtypes

Ah, I get it now. Yes, then it sounds like such an alternate constructor, with the orient keyword, would be very useful and would simplify some calls. If you do implement it, you might want to make note of its existence in the docstring for __init__, so people look for it instead of writing their own workarounds against the main __init__. Thanks!!

OK, I wrote a DataFrame.from_items that I think does the right thing-- added some notes to the DataFrame docstring about other constructors, too

Thanks @wesm!