Language design

Mark Janssen dreamingforward at gmail.com
Wed Sep 11 20:49:09 EDT 2013


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

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

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

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

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

--mark



More information about the Python-list mailing list