Why are so many built-in types inheritable?

[Georg Brandl]

Antoon Pardon wrote:
> 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.

Which wasn't true in older versions of Python. lst[x:y] was a special
syntax construct calling a special method __getslice__. Slice objects
were merely introduced to simplify index handling.

> 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?

Point taken, now that slicing creates slice objects this would be
consistent. IIRC, there was indeed a PEP suggesting to introduce a range
literal which would have made this possible.

>> 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.

Being? I mean, developer time isn't available en masse, and an overly
strict view on purity might sometimes actually prevent a feature being
implemented.

Georg