Language design

[Steven D'Aprano]

By the way, please keep attributions for those you are quoting. It is 
rude otherwise.


On Wed, 11 Sep 2013 17:49:09 -0700, 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?

Not directly, that would be silly. But if you derive from int, or dict, 
or ValueError, or any other type, you're indirectly deriving from object 
since they derive from object. In Python 3, *everything* derives from 
object.

In Python 2, the situation is slightly different in that there are still 
legacy ("old style" or "classic") classes, but that's an old version of 
Python. It's not quite obsolete as yet, but in another five years or so 
it will be. The important thing is, as of *right now*, there are Python 
versions where object is the base class of every class.



>>> No one's close enough to God to make that work.
>>
>> Non-sequitor. One doesn't need to be close to a deity to have a single
>> root of the object hierarchy.
> 
> But wait is it the "base" (at the bottom of the hierarchy) or is it the
> "parent" at the top?  You see, you, like everyone else has been using
> these terms loosely, confusing yourself.

Depends on whether I'm standing on my head or not.

Or more importantly, it depends on whether I visualise my hierarchy going 
top->down or bottom->up. Both are relevant, and both end up with the 
*exact same hierarchy* with only the direction reversed.


>>> 2) It didn't make dicts inherit from sets when they were added to
>>> Python.
>>
>> Why would you want dicts to inherit from sets?
> 
> A dict is-a set of {key:object, key:object} pairs bound together with a
> colon ":".  

It certainly is not.

py> {'x': []}  # Lists can be in dicts.
{'x': []}
py> set([[]])  # But not in sets.
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'



> By inheriting from sets you get a lot of useful
> functionality for free.  That you don't know how you could use that
> functionality is a failure of your imagination, not of the general idea.

No you don't. You get a bunch of ill-defined methods that don't make 
sense on dicts.


For example: what is the intersection of these two dicts?

{'a': 1, 'b': 3}
{'a': 3, 'b': 5}


I can see SIX possibilities:

{}
{'a': 1, 'b': 3}
{'a': 3, 'b': 5}
{'a': 3}
{'b': 3}
raise an exception



>>> 3) It used the set literal for dict, so that there's no obvious way to
>>> do it.  This didn't get changed in Py3k.
>>
>> No, it uses the dict literal for dicts.
> 
> Right.  The dict literal should be {:} -- the one obvious way to do it. 

I don't agree it is obvious. It is as obvious as (,) being the empty tuple 
or [,] being the empty list.




> Pay me later.
> 
>> And the obvious way to form an empty set is by calling set(), the same
>> as str(), int(), list(), float(), tuple(), dict(), ...
> 
> Blah, blah.  Let me know when you got everyone migrated over to
> Python.v3.

What does this have to do with Python 3? It works fine in Python 2.


>>> 4?) It allowed
>>> [reference] variables to be used as dict keys.  This creates a parsing
>>> difficulty for me, mentally.  Keys should be direct, hashable values,
>>> not hidden in a variable name.
>>
>> I don't even understand what you are talking about here. "[reference]
>> variables"? What does that mean?
> 
> It's a just a tricky point, that I will wait to comment on.

I'm looking forward to an explanation, as I'm intrigued.



-- 
Steven