Why are so many built-in types inheritable?

[Antoon Pardon]

Op 2006-03-31, Georg Brandl schreef <g.brandl-nospam at gmx.net>:
> Antoon Pardon wrote:
>
>> Well that looks somewhat short sighted to me. It is also why python
>> seems to throws so many surprises at people.
>> 
>> My impression is that quite frequently people come here with a question
>> about why something doesn't work, that normally could be expected to
>> work.
>
>> The reason why it doesn't work then seems to boil down to the
>> developpers not taking the trouble of implementing something
>> in general but only for the cases for which they could imagine
>> a use case. Which means that when someone comes up with a use
>> case later he is stuck.
>
> I think you're overgeneralizing here. Do you have other examples of
> such a strategy resulting in something that doesn't work although
> it should?

That is a very subjective question. I'm sure some will think
there is no reason why subclassing slices or functions should
work and so will not even consider this as something that
doesn't work but should.

But I will give you one example.

Consider the following:

  lst[3:7:2]

What does it do? It constructs a slice object which is then used
as an index in lst.

So why doesn't this work:

  fun(3:7:2)

What is wrong with expecting that a slice object would be constructed
here which would then be used as an argument for the function call?

> Nota bene: Often developers run into a limitation that is the result
> of a deliberate design choice, such as "why aren't strings mutable?"

Well that is fine, but in this case I haven't seen such a design
choice explained. On the contrary the only thing that I have
heard in this case is that is wasn't implemeted because noone
submitted a patch. So it seems hardly the result of a deliberate
design choice in this case.

>> I know about practicality beating purity, but purity has it
>> practical aspects too. If the python people had been willing
>> to work a bit more at purity, that would have been a lot
>> of more practical for those who found something not working
>> as expected, although they had no reason to suspect so.
>
> I've told you already: if a developer wants a feature not currently
> implemented, he/she can
>  - ask on python-dev why
>  - submit a feature request
>  - submit a patch
>
> If he/she's not able to do one of these, he/she can at least convince some
> other Python developer if the use case is strong enough.

Yes you told this already, and it ignores completely the point
I am trying to make. There is a point here beside convincing
the devolopers to implement this.

-- 
Antoon Pardon