More efficient/elegant branching

[Daniel Haude]

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.