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

ENH: Revise Python API for loading/saving games #357

Open
tturocy opened this issue Sep 21, 2023 · 1 comment
Open

ENH: Revise Python API for loading/saving games #357

tturocy opened this issue Sep 21, 2023 · 1 comment
Assignees
Labels
python Items which involve coding in Python
Milestone

Comments

@tturocy
Copy link
Member

tturocy commented Sep 21, 2023

Game objects currently just have generic .read_game and .write_game operations, where .write_game takes a format parameter to determine the output format, while .read_game tries various formats until one is successful.

Looking at e.g. pandas, it seems it would be better to have functions that explicitly read and write the different supported formats.

@tturocy tturocy added the python Items which involve coding in Python label Sep 21, 2023
@tturocy tturocy added this to the gambit-16.2.0 milestone Sep 29, 2023
@tturocy tturocy modified the milestones: gambit-16.2.0, gambit-16.3.0 Feb 9, 2024
@tturocy
Copy link
Member Author

tturocy commented Jul 16, 2024

As an initial concrete proposal, we suggest we'll follow the conventions that pandas uses in its I/O functions. Specifically, one can look at read_csv (https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.read_csv.html) and to_csv (https://pandas.pydata.org/docs/reference/api/pandas.DataFrame.to_csv.html).

Specifically, we will have the following:

  • The functions for reading files will be module-level in pygambit. (The current functions are all part of the Game class.)
  • When reading, the first argument should be a string, path object, or file-like object, just like read_* in pandas.
  • When writing, the first argument is optional, and can be a string, path object, or file-like object, or null. If null, the function returns the serialised string representation.

We will have the following functions (please add a note if there are others that are missing)

  • Reading
    • read_efg - reads an .efg file format
    • read_nfg - reads an .nfg file format
    • read_gbt - reads a .gbt file (XML files produced by the GUI)
    • read_agg - reads an action-graph games file format
  • Writing
    • Game.to_efg - writes an .efg file
    • Game.to_nfg - writes an .nfg file
    • Game.to_gbt - writes a .gbt file
    • Game.to_html - writes out HTML tables
    • Game.to_latex - currently the sgame format supported by Game.write.
    • (there is not at present support for writing out AGG files so no need to have this as yet)

The function Game.parse_game will be deprecated, as its functionality can be replicated by wrapping such a string in an io.StringIO object and then passing it to the appropriate read_* function as above, which functions will now accept file-like objects.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
python Items which involve coding in Python
Projects
None yet
Development

No branches or pull requests

2 participants