General question about Python design goals

[Chris Mellon]

On 11/30/05, Christoph Zwerschke <cito at online.de> wrote:
> bonono at gmail.com wrote:
> Paul Rubin wrote:
> Look at the list.count() example at the start of this thread.
> Diagnosing it isn't hard.  Curing it isn't hard.  It doesn't bloat
> Python by an order of magnitude.  A suitably factored implementation
> might handle lists and strings with the exact same code and not
incur
> any extra cost at all.  That type of thing happens all the time
here.
> 
> I believe the language creator use the "lack of" as a way to
> prevent/discourage that kind of usage. Just like the ternary
> operator(still don't know why it is finally accepted). It is not a
> problem(not having), it is a feature(to teach you program better),
so
> what cure are we talking about ?
> 
> Sorry, but I still do not get it. Why is it a feature if I cannot
count
> or find items in tuples? Why is it bad program style if I do this?
So
> far I haven't got any reasonable explanation and I think there is
no.
> 
> -- Christoph
> 

I'd have to say this:

First, remember that while your idea is obvious and practical and
straightforward to you, everybodys crummy idea is like that to them.
And while I'm not saying your idea is crummy, bear in mind that not
everyone is sharing your viewpoint.

If you want to make changes to the language, you need to be prepared
to convince other people that your idea really is a good one.
Therefore:

Be prepared to present a use case. If your idea really is
straightforward, simple, and obvious this should be fairly easy. It is
possible that your idea is so simple and obvious that everyone will
agree with it, do not expect this to be the case no matter how simple
and obvious it seems to you.

Be prepared to defend your use case. If people show reasons why your
use case is invalid, be prepared to consider that you may be wrong. If
you're still sure that you aren't, present a different use case -
don't expect other people to imagine one for you.

If you *really* want a language feature changed, be prepared to
present a patch for it. If you aren't willing or able to implement it
yourself, you must convince someone else that not only is your change
a good idea, but that it's a good enough idea that they should work on
it, which is always more of an uphill battle.

There may be different subjective or conceptual reasonings at work -
like you wanting to treat tuples as first class sequences while others
(like Guido) want to treat them otherwise. There's no right answer in
a subjective argument, so be prepared to present practical support,
and, unless you're the BDFL, be prepared to be ignored. If it bothers
you enough, you know what your options are.