[Tutor] What's in a name.

[Cameron Simpson]

On 19May2023 01:45, ThreeBlindQuarks <threesomequarks at proton.me> wrote:
>I appreciate the correction Cameron. How much does it narrow things if 
>the goal is to only have one OBVIOUS way?

Well, "obvious" is a subjective term. The design objective expressed in 
the Zen is that for _common_ tasks, there should be an obvious way to do 
it (which will be correct, i.e. not misleadingly named or with confusing 
semantics).

It's not a statement that this will always be the case, just an 
expression that this is desirable most of the time. Ergonomics, ease of 
correct use.

>I have seen too many places where even the obvious ways were too numerous.

Doubtless. But if (to take your "suffix" based examples) there are many 
choices, maybe this is a hint that the class you're working on (if it is 
a class) could do with a purpose built method implementing the commonly 
preferred way.

>If I ask you to take a string and substitute in various parameters held in variables, which method is obvious?

That can be a complex task, but probably str.format these days.

>At least five major methods are supported that overlap quite a bit and some have relatively unique features. These days, some might argue you should mainly just use an f-string but clearly older code mainly used other methods and there is no pressure to change.

Right. Historic features don't go away because that would break code.  
But if there's a _good_ new feature then that should become the "obvious 
way to do it" for the common cases.

[...]
>I am not making fun of Python but continue to not take seriously anyone 
>who truly believes there are usually obvious ways to do things in a 
>language like Python. I submit many people either do not know the 
>Pythonic way that others claim is a thing or disagree with it at times.
[...]

Reiterating: it is a design objective, both for things in the stdlib and 
for Pythonic code people are writing anew. It isn't always met, and if 
the use cases are new or nebulous it _can't_ be met in any universal 
way. It's just saying that Pythonic code should hopefully offer obvious 
choices for common needs.

Cheers,
Cameron Simpson <cs at cskk.id.au>