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

load vs loads #448

Closed
oleg-alexandrov opened this issue Apr 28, 2022 · 5 comments
Closed

load vs loads #448

oleg-alexandrov opened this issue Apr 28, 2022 · 5 comments

Comments

@oleg-alexandrov
Copy link
Collaborator

I got bitten on a few occasions about the fine distinction between 'load' and 'loads', especially that in English the "s" has its own grammatical use and one easily glosses over it.

I think the loader functions should be called something like "load_as_dict" and "load_as_str" for clarity. The current "load" and "loads" could still be maintained as aliases.

@jessemapel
Copy link
Contributor

ALE uses the same convention as the Python JSON package where load/dump work with objects and loads/dumps work with strings.

I have also confused myself with this, but it's more in line with the base Python package.

@Kelvinrr I'm curious if you have thoughts on this as someone more familiar with Python packages.

@oleg-alexandrov
Copy link
Collaborator Author

oleg-alexandrov commented Apr 28, 2022

That a certain Python JSON package uses this convention is a little bit of cold comfort. :)

@jessemapel
Copy link
Contributor

It is the built-in Python JSON package, so it's a bit of a convention.

I'm hesitant to change the name of the primary function for this package. We could add "alias" functions. I think this will also be largely alleviated by #437

@oleg-alexandrov
Copy link
Collaborator Author

Sure. I think we should have a user-facing perspective and not an existing-package-facing perspective, but hey, whichever works. If aliases are added and documented in the readme, maybe that will make everybody happy. I can put a pull request if this makes sense.

@antonhibl
Copy link
Contributor

addressed largely by #437

@antonhibl antonhibl closed this as not planned Won't fix, can't repro, duplicate, stale Jan 12, 2023
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