On 30 Aug 2021, at 18:19, Christopher Barker <pythonchb@gmail.com> wrote:
On Mon, Aug 30, 2021 at 12:57 AM Ronald Oussoren <ronaldoussoren@mac.com <mailto:ronaldoussoren@mac.com>> wrote:
On 28 Aug 2021, at 07:14, Christopher Barker <pythonchb@gmail.com <mailto:pythonchb@gmail.com>> wrote:
Also +1 on a string flag, rather than an Enum. ou prefer strings for the options rather than an Enum? The enum clearly documents what the valid options are for the option.
So does documentation (docstrings, useful error messages). I don't think the documentation built in to an Enum is any easier to access.
The enum definition shows the valid names that can be used, string literals are more open ended. Documentation helps, but can get out of sync.
In fact, looking now, I'm trying to see how an Enum provides any easy to access documentation -- other than looking at the creation code. As a rule, I don't think Enums provide documentation of the valid values, but rather, enforcement.
e.g.: what are the valid values? what do they mean?
To be honest, I haven't really used Enums much (in fact, only to mirror C enums in extension code), but part of that is because I have yet to see what the point is in Python, over simple string flags.
I suppose they provide a real advantage for static typing, but other than that I just don't see it.
Not just static typing, but static analysis in general. Tools like flake8 will complain about typos, completion tools can help typing, ….
But what they do is create a burden of extra code to read and write. Compare:
from statistics import median
result = median(the_data, nan_policy='omit')
with:
from statistics import median, NaNPolicy
result = median(the_data, nan_policy=NaNPolicy.Omit)
or maybe:
import statistics as stats
result = stats.median(the_data, nan_policy=stats.Omit)
It is not necessarily a hard choice, it is possible to define enums that can be compared with strings, such as: class NanPolicy(str, enum.Enum): ….
There are any number of ways to import, and names to create, but they all seem to me to be more awkward to use than a simple text flag.
Ever since I started using Python, I've really appreciated the use of string flags :-)
I tend to use constants instead of string literals because of better static analysis, and try to convert uses to enums over time. String flags work as well, but I’ve had too much problems due to typo’s in string literals that weren’t caught by incomplete tests. Being able to at least run a listing tool to find basic issues like typo’s is very convenient. But YMMV.
I do see how using an Enum makes things a bit easier for the author of a package (more DRY), but I don't think that should be the priority here.
No one needs to convince me, but I would be interested in seeing the recommended way to import and use Enum flags - maybe it doesn't have to be as awkward as I think it is.
I have no opinion on this particular API discussion, my question was out of interest in this particular remark. Ronald
-CHB
-- Christopher Barker, PhD (Chris)
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
— Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/