Language design

Terry Reedy tjreedy at udel.edu
Wed Sep 11 21:40:39 EDT 2013


On 9/11/2013 8:49 PM, Mark Janssen wrote:
>>> 1) It tried to make Object the parent of every class.
>>
>> Tried, and succeeded.
>
> Really?  Are you saying you (and the community at-large) always derive
> from Object as your base class?

The name is 'object', and yes, everyone does it because it is automatic. 
(I am including indirect inheritance, and excluding weird metaclass games.)

 >>> class C(): pass

 >>> dir(C)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', 
'__init__', '__le__', '__lt__', '__module__', '__ne__', '__new__', 
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', 
'__str__', '__subclasshook__', '__weakref__']

Just *where* do you think all those methods come from.

>>> C.__bases__
(<class 'object'>,)

> But wait is it the "base" (at the bottom of the hierarchy) or is it
> the "parent" at the top?

This sort of quibbling should be beneath you.

> A dict is-a set of {key:object, key:object} pairs bound together with
> a colon ":".

Yes... but there is a very important additional condition: each key 
appears only once.

Humans are primates, but that is not a sufficient characterization.

 > By inheriting from sets you get a lot of useful
> functionality for free.

Actually, you get a lot of un-useful functionality for free. Because of 
the extra condition, the rule for adding a key:object pair to a dict is 
different from the rule for adding a key:object pair to a set of such 
pairs. The set-union of two dicts is not necessarily a dict. To put is 
another way, dicts as set subclasses would violate the Liskov 
Substitution Principle.

'Homogenous' sets (of strings, numbers) would be proper subclasses of set.

> Right.  The dict literal should be {:}

and the set literal 'should' be {}, and would be if Python were 
redesigned from scratch. Is your imagination so stunted that you 
actually think we did not discuss that when designing Python 3?
We did, but Guido rejected switching because he thought it would cause 
too much pain and discourage adoption of Python 3 even more than the 
other code-breaking changes that were made.

-- 
Terry Jan Reedy




More information about the Python-list mailing list