The type/object distinction and possible synthesis of OOP and imperative programming languages

[Antoon Pardon]

Op 16-04-13 18:49, Terry Jan Reedy schreef:
> On 4/16/2013 5:07 AM, Antoon Pardon wrote:
>> Op 16-04-13 05:17, Terry Jan Reedy schreef:
>>
>>> I will keep the above in mind if I write or review a patch. here are 4
>>> non-subclassable builtin classes. Two are already documented. Bool in
>>> one, forget which other. I believe it was recently decided to leave
>>> the other two as is given the absence of any practical use case.
>>
>> Why should there be a practical use case here?
>
> As a practical matter, the change is non-trivial. Someone has to be
> motivated to write the patch to enable subclassing, write tests, and
> consider the effect on internal C uses of slice and stdlib Python used
> of slice (type() versus isinstance).
I see. It seems I have underestimated the work involved.

>> I once had an idea of a slice-like class that I would have liked to
>> experiment with.
>
> Did the idea actually require that instances *be* a slice rather than
> *wrap* a slice? 

As far as I remember I wanted my slice object usable to slice lists
with. But python doesn't allow duck typing when you use your object to
"index" a list. No matter how much your object resembles a slice, when
you actualy try to use it to get a slice of a list, python throw a
TypeError with the message "object cannot be interpreted as an index".
This in combination with slice not being subclassable effectively killed
the idea.

As I already said I don't know if the idea would have turned up
something usefull. The following years I never had the feeling how great
it would have been should I have been able to pursue this idea. I just
thought it was a pity I was so thoroughly stopped at the time.

-- 
Antoon Pardon