Use pathlib library to handle filenames

[sybreton]

The filename that is read by the read_data function currently assumes that self.file_name is a string and checks the file suffix with the string method endswith. However, this prevents from passing to the function a Path object created e.g. with the pathlib library, which might prove problematic when integrating the mesa_reader in other module test procedure, where the path to the profile to read cannot be anything else than a Path object.

The fix uses the pathlib library in order to check the suffix of self.file_name (in read_data) with the pathlib library suffix attribute.

[wmwolf]

I'm not totally opposed to making this compatible with pathlib, but importing two new modules in adds some complexity to a rather simple tool. I wonder if we could just cast self.file_name to a string before using plain old endswith. The code would still be agnostic to whether the file name is a string or a path object. Do you see any likely issues with that?

[ShaiAvr]

In my opinion, it's much better to use pathlib rather than plain strings. It's precisely the reason this library exists. It's a lot easier to manipulate and inspect Path objects than plain strings. I would argue that self.file_name and any other file related properties and variables should be stored as Path objects instead of a strings to begin with. It would make it much easier to handle both for us and the users. A Path object is compatible almost everywhere a string representing a path is required, such as when using open and even os.path functions (they can accept Path objects, but will still return strings). As a result, most users won't even notice if they get a string or a Path object, and if they really want a string, they can just use str(path).

[sybreton]

I totally agree with the point raised by @ShaiAvr.

@wmwolf, about your concern related to importation I do not see this as a particular issue in this case as pathlib is part of the Python standard library, so it does not require any additional installation.

(you mention the importation of two new modules, I do not really understand why, actually the only new module is pathlib)

[wmwolf]

Sorry for going silent on this; the semester ending is always hectic. Given that it seems I have fallen behind the times on the standard library, I agree that this is a better approach. I will try to make sure that there are no unintended surprises that would be caused by this cahnge, but then I will issue a new release soon with pathlib as the backend. Thanks for your contribution, @sybreton!

[sybreton]

Perfect, thanks a lot !