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

Antoon Pardon antoon.pardon at rece.vub.ac.be
Tue Apr 16 05:07:38 EDT 2013


Op 16-04-13 05:17, Terry Jan Reedy schreef:
> On 4/15/2013 10:32 PM, Steven D'Aprano wrote:
>> On Mon, 15 Apr 2013 20:52:58 -0400, Terry Jan Reedy wrote:
>
>>> Some builtin classes cannot be subclassed. There is an issue to
>>> document
>>> which better. That does not mean that it is not a class.
>>
>>
>> I think it is also important to document whether that is a language
>> feature, or a mere restriction of the implementation. There is an
>> important distinction to be made between:
>>
>> "In CPython, you cannot subclass slice or FunctionType. Other Pythons
>> may
>> have more, or fewer, restrictions."
>>
>> and:
>>
>> "No language that calls itself Python is permitted to allow slice and
>> FunctionType to be subclassable."
>>
>>
>> If I had a say in this, I would vote for the first case, with the
>> possible exception of documented singleton types like NoneType and bool.
>
> 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? Since classes are in
general subclassable, shouldn't you have a reason to not make them so
instead of people needing to give you a practical use case before you
treat them as you do most of them?

I once had an idea of a slice-like class that I would have liked to
experiment with. As things were I didn't get far because slice not being
subclassable was a major hurdle in getting it practical. Would the end
result have been a practical use case? I don't know, I didn't get the
chance to find out because making a class that looked like a slice
didn't work either. Python wanted, maybe still wants, a real slice in a
number of circumstances and not a ducktyped slice-like object.

Now maybe there are good reasons for slice not being subclassable but
there not being a practical use case doesn't seem to be one in this case.



More information about the Python-list mailing list