Skip to content

Default output_format to "dataframe" #1115

Open

Description

@PGijsbers

I propose that the several functions that take the ouput_format parameter and produce lists change their defaults to return dataframes instead of dictionaries (e.g. list_datasets).
I think originally we had loose integration with pandas and it was an optional dependency, but since it's a required dependency now I don't see a reason to provide dicts as default over dataframes. I'd argue most people prefer dataframes in interactive sessions, and it makes sense to minimize the amount of writing people have to do in those (also plenty of people might prefer dataframes in scripts too).

Activity

  1. mfeurer commented on Oct 27, 2021

    @mfeurer
    Collaborator

    I fully agree to this suggestion. Indeed, dataframes were added later and have matured substantially since then and I guess we can consider handling them standard knowledge for machine learners.

  2. added
    Good First IssueIssues suitable for people new to contributing to openml-python!
    on Oct 27, 2021
  3. amastruserio commented on Apr 18, 2022

    @amastruserio
    Contributor

    I took a look at this to see how the proposed changes would behave and it appeared to lead to a few issues with some functions not fully integrated with dataframes yet. Many of these errors were Attribute errors centering around flow_id, task_id, and run_id, and appear to be the result of some functions expecting objects other than dataframes.
    It also lead to repeated unit test failures involving Key_Errors, namely with flow_id, task_id, and uploader.
    There were also some assertion errors that wanted to assert some object was a dict, but I imagine these assertions would be irrelevant with dataframes as the default.
    I have a complete list of unit tests that failed after implementing these changes that I can provide as well, but I think there is still more integration with dataframes needed from the codebase before being able to totally implement this change.

  4. PGijsbers commented on Apr 19, 2022

    @PGijsbers
    CollaboratorAuthor

    In that case it might be best to do this incrementally. First we'd get a PR that changes the default, but makes internal calls use the explicit output_format="dict" so you can change the external behavior without making many internal changes. We could then further refactor the internal handling of the data in separate PRs where it makes sense.

  5. added this to the 0.14.0 milestone on Nov 29, 2022
  6. self-assigned this
    on Jun 15, 2023
  7. varshneydevansh commented on Aug 9, 2023

    @varshneydevansh
    Contributor

    Hi!

    I am not sure how I ended up here, but I looked at what you guys are doing and It's pretty remarkable. I find this challenge to be my starter in this project and would love to contribute more. =)

  8. PGijsbers commented on Aug 10, 2023

    @PGijsbers
    CollaboratorAuthor

    Hi @varshneydevansh, thank you! We already started working on this, as can be seen in #1258. It's already assigned to me since it's pretty involved. However, if you would like to do this instead, here is basically what needs to be done:
    The next step is to actually make the change and make output_format='dataframe' the default as well as removing output_format='dict' support wherever the message indicated it. You should be able to find all instances of this in # TODO: [0.15]. Then, make sure to update any unit tests necessary and update the documentation.

    If you'd like something smaller, I could recommend you to work on #1142 or #1213 (the latter requires some Github Actions knowledge, but no knowledge of our code-base).

  9. PGijsbers commented on Oct 14, 2024

    @PGijsbers
    CollaboratorAuthor

    We missed this in the 0.15 release, adding it to 0.16

  10. removed their assignment
    on Oct 14, 2024
  11. modified the milestones: 0.14.0, 0.16.0 on Oct 14, 2024
  12. Roshangoli commented on Apr 29, 2025

    @Roshangoli
    Contributor

    Hi! I’m new to open source and was excited to contribute to this issue as my first task, but I see it’s already being handled in PR #1390. Could I please be recommended a similar beginner-friendly issue to get started with? Thank you! 🙌

  13. Omswastik-11 commented on Nov 16, 2025

    @Omswastik-11
    Contributor

    Hi @PGijsbers !!
    is this issue open ? Should I work ?

  14. anisha-04 commented on Jul 23, 2026

    @anisha-04
    Contributor

    I plan to work on a narrowly scoped solution for this issue and add deterministic tests covering the reported behavior.

  15. AtharvaManale commented on Oct 11, 2026

    @AtharvaManale

    Hi @PGijsbers
    I investigated this issue against the current codebase and traced the implementation in your pr #1258.

    In PR #1258 I can see the conversion of output_format="dict" to output_format="dataframes" for return values has been implemented and also handled the domino effect of that change which affected multiple unit tests and functions related to datasets, tasks, flows, evalutions, runs and studies.

    I suggest closing this issue if there are no further requirements.

  16. PGijsbers commented on Oct 12, 2026

    @PGijsbers
    CollaboratorAuthor

    Thanks for spotting this issue was already (mostly) done. I had a look myself and it looks like list_setups currently still defaults to dictionary output. It was probably missed because it's referenced as "object" rather than "dict".

  17. arcwiser commented on Oct 12, 2026

    @arcwiser

    I’ll work on the remaining list_setups gap identified above: make its public default DataFrame output, keep internal callers explicit where needed, and update focused tests and documentation.

  18. AtharvaManale commented on Oct 12, 2026

    @AtharvaManale

    Hi @PGijsbers

    I had a look myself and it looks like list_setups currently still defaults to dictionary output. It was probably missed because it's referenced as "object" rather than "dict".

    I have reviewed this pr #1769 by @arcwiser regarding the missing list_setups default_output = ''object" to "dataframe".
    Also tested and ran the following test cases locally, it is a great pr to take a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions