Skip to content
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

harmonize construction behavior #191

Closed
gidden opened this issue Feb 11, 2019 · 3 comments
Closed

harmonize construction behavior #191

gidden opened this issue Feb 11, 2019 · 3 comments

Comments

@gidden
Copy link
Member

gidden commented Feb 11, 2019

There are a number of functions which "construct" dataframes, e.g., concat() and append(). How these work should be harmonized to a common data model.

At the moment, concat() requires that all input be pyam.IamDataFrames. append() on the other hand, can take any castable object such as pd.DataFrame or even file names which are read in at execution time.

The pros and cons deal with user experience vs. explicit interfaces using native datatypes. It is not clear which outweighs the other, so further comments from devs and users is appreciated.

So let us assume you have data in two files a.csv and b.csv that you want to combine. The options would look as follows:

User Experience

pyam.IamDataFrame('a.csv').append('b.csv')
pyam.concat(['a.csv', 'b.csv'])

Explicit Interfaces

pyam.read_file('a.csv').append(pyam.read_file('b.csv'))
pyam.concat([pyam.read_file('a.csv'), pyam.read_file('b.csv')])

The trickiness here is that our constructor currently supports two primary castable types: pd.DataFrames and files. If we choose "Explicit Interfaces", that would suggest that we no longer support reading files directly in pyam.IamDataFrame.__init__ .

Thoughts? @znicholls @danielhuppmann others?

@danielhuppmann
Copy link
Member

strongly in favour of the "User Experience" option, see #190 (comment)

note that the IPCC notebooks at https://github.com/iiasa/ipcc_sr15_scenario_analysis all use pyam.IamDataFrame('<file>'), so that would introduce an incompatibility going forward...

@znicholls
Copy link
Collaborator

I'd be in favour of the user experience too and refactoring the back end so they all get sent to the same format_data (or similar) pipeline which handles all the different possibilities

@danielhuppmann
Copy link
Member

I think that having merged #199, we have implicitly decided on the way forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants