There's some differences to the API that was described in #53
data.file() is called here data.file_path() (same for code_file_path etc). This is because file is a builtin type in python and data.file() gets syntax highlighted funnily even though it is a valid method name. I think file would be ideologically better but file_path is more pragmatic in this situation and thus I chose to use it.
I went with data over dataset as that's what the R API seems to be using now and also I don't see any downside to calling it data over dataset. However the class is still called Dataset internally but changing that won't affect the user facing API so I can do that a bit later.
I ended up dropping the shortcut methods like posterior.data_file_path(), instead posterior.data.file_path() should be used. I feel like the shortcuts don't really add anything (in this case the difference is _ vs .) and it's more clear if there's only one way to do something. It also makes the library simpler, which is always good.
Fixes #53
There's some differences to the API that was described in #53
data.file()
is called heredata.file_path()
(same forcode_file_path
etc). This is becausefile
is a builtin type in python anddata.file()
gets syntax highlighted funnily even though it is a valid method name. I thinkfile
would be ideologically better butfile_path
is more pragmatic in this situation and thus I chose to use it.data
overdataset
as that's what the R API seems to be using now and also I don't see any downside to calling itdata
overdataset
. However the class is still calledDataset
internally but changing that won't affect the user facing API so I can do that a bit later.posterior.data_file_path()
, insteadposterior.data.file_path()
should be used. I feel like the shortcuts don't really add anything (in this case the difference is_
vs.
) and it's more clear if there's only one way to do something. It also makes the library simpler, which is always good.