General question about Python design goals

[Christoph Zwerschke]

>>Let me ask back: Do I really need to bother and justify it with a use 
>>case in a case where the language can be easily made more consistent or 
>>orthogonal without breaking anything?

Robert Kern wrote:

> Yes. If it's not going to be used, then there's not much point.
> Practicality beats purity, and all that.

I have nothing against "practicality beats purity". But to stay with the 
examples I have given, in how far is writing list(t).index(x) more 
practical than t.index(x)?

And by the way, if we are speaking about practicality here, are we 
speaking about practicality for the Python developers or for the Python 
users? This may be sometimes be in opposition.

Let me give an extreme example: Assume the count() method for strings 
would have been called "numberofsubstringsinthestring()" and I argue it 
should be called "count()" because that is shorter and how it is called 
for lists. What should I give as a "use case" here? Must I give "use 
cases" if the issue is about convenience/simplicity/elegance?

> However, I will note that if you were to present us with a working patch
> with documentation and unittests, then you'll probably get responses
> along the lines of "Thank you!", instead.

Not everybody has the time and skills to provide that. Ordinary people 
from the Python user base should be given the opportunity to make 
suggestions for improvement - of course not in the tone of "I 
demand...", but they should not be automatically regarded as "demanding" 
if they just utter their opinion or make a suggestion either.

Even if I had the time and skills, before starting to work on a patch, 
unittests etc. I still would first discuss with others whether my 
suggestion is reasonable and would be appreciated by the "user base", 
developers and the BDFL. Just take the example of the following patch:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=403693&group_id=5470

It was not rejected by reason of missing unittests or documentation, but 
the very idea was rejected.

Actually, I'm not keen on being a protagonist for this issue or starting 
a hard-bitten discussion about this and defend the idea if everybody is 
against or nobody cares. It does not bother me that much either.

But it just led me to the general question: Which significance actually 
have design features such as orthogonality for Python?

-- Christoph