Hello Neil,
thanks for the detailed answer.
Question: are there other people/factors who/which should be regarded
as more important than the linter's opinion?
Yes. Mine.
I was just puzzled at the linter's output (took me a while to figure out
what it actually meant), and that got me started on the track if there
was maybe a more Pythonic way of dealing with that decision chain.
The usual dictionary-controlled construct I've seen (and used)
involves using functions as the dict's values:
[...]
Yeah, I do that a lot, too, but for that you need a meaningful "key"
object. In the case at hand, I'm really using individually formulated
conditions.
Is it ironic that the language does not have a form of case/switch
statement (despite many pleas and attempts to add it),
Wouldn't do me any good here because case/switch also compares a fiked
key against a bunch of candidates, like a dict. Also, in terms of line
count the if/elif chain isn't worse than a switch statement.
yet the linter objects to an if-elif-else nesting???
Like I said, that's what got me started on this. And it's not even
nested, it's purely linear.
One reason why this code looks a bit strange (and possibly why PyLint
reacts?) is because it is trivial. When we look at the overall
picture, the question becomes: what will the 'mainline' do with
"result" (the returned value)? Immediately one suspects it will be fed
into another decision, eg:
No, the "result" is a text message that actually means something and is
eventually output for human consumption.
The whole thing is rather academic. Also my efficiency argument doesn't
hold water because this routine is executed just a few times per hour. I
like the "condition table" approach for its lower line count but I'll
stick with if/elif because it's more conventional and therefore easier
to understand for the casual reader.
--
https://mail.python.org/mailman/listinfo/python-list
