CalebBell / chemicals

chemicals: Chemical database of Chemical Engineering Design Library (ChEDL)
MIT License
186 stars 36 forks source link

Method lists and names #6

Closed yoelcortes closed 4 years ago

yoelcortes commented 4 years ago

@CalebBell I was wondering if there is any reason we'd like to keep the lists of methods (e.g. Tc_methods and Pc_methods) as well as the method strings (e.g. IUPAC = 'IUPAC'). I think the docstrings and the ability to get available methods already serve this purpose. Also, naive users might get the false impression that they can be altered to remove methods. Is there any dependencies on these? Please let me know if you're fine with dropping these. I'd be happy to remove them from the code and the documentation as well.

CalebBell commented 4 years ago

Hi Yoel, The reason people use the method constants is to 1) improve performance a little 2) cleaner code 3) it trades having the same string all over your files, by having... another string! But this one will be auto-completed by a good IDE, which makes programming with it easier. I agree it seems weird but it is common in programming and seems to pay off. I use the format at work and it seems kinda to pay off the larger the project is and the more people are involved in the code base. But I confess I do not use it elsewhere; the flow_meter module is the only thing in fluids using it for example.

The list of methods is aimed at having a programmatic way of iterating over all the methods that can be used. I have used it for tests elsewhere. Ideally the exception raised when an incorrect method is given, should contain a return value listing all the possible string inputs as well. Having that list is a convenient way to generate that exception text.

yoelcortes commented 4 years ago

Ohh wow, thanks a bunch for the explanation! That's some good coding practice. I feel like I'm in training jaja