So, the high-level API has the Python-traditional load(s)/dump(s) naming scheme. Since I modified the DataReader class some time ago, this isn't strictly necessary for the load(s) functions anymore. But, it makes the code nicer and easier to raise an exception on incorrect parameters. Also, explicit is better than implicit here, especially considering there is a need to have both dump and dumps.
So far, all of the format and component classes have been using load classes that handle everything as it just casts the data argument to a DataReader. But, this should certainly be confusing, or at least inconsistent.
I propose to rename the loading class builder methods to parse, taking any DataReader-compatible input as now and returning on instance of the class, and naming the dumping methods format, returning a bytes object.
So, the high-level API has the Python-traditional
load(s)/dump(s)naming scheme. Since I modified theDataReaderclass some time ago, this isn't strictly necessary for theload(s)functions anymore. But, it makes the code nicer and easier to raise an exception on incorrect parameters. Also, explicit is better than implicit here, especially considering there is a need to have bothdumpanddumps.So far, all of the format and component classes have been using
loadclasses that handle everything as it just casts thedataargument to aDataReader. But, this should certainly be confusing, or at least inconsistent.I propose to rename the loading class builder methods to
parse, taking anyDataReader-compatible input as now and returning on instance of the class, and naming the dumping methodsformat, returning abytesobject.