Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail
MIME-Version: 1.0
In-Reply-To: <52315238$0$29999$c3e8da3$5496439d@news.astraweb.com>
References: <522eb795$0$29999$c3e8da3$5496439d@news.astraweb.com> <mailman.270.1378935062.5461.python-list@python.org> <5230ff66$0$29988$c3e8da3$5496439d@news.astraweb.com> <mailman.287.1378946951.5461.python-list@python.org> <52315238$0$29999$c3e8da3$5496439d@news.astraweb.com>
Date: Thu, 12 Sep 2013 20:23:21 -0700
Subject: Re: Language design
From: Mark Janssen <dreamingforward@gmail.com>
To: "Steven D'Aprano" <steve@pearwood.info>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Python List <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.338.1379042609.5461.python-list@python.org>
Lines: 75
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:54097

>> Really?  Are you saying you (and the community at-large) always derive
>> from Object as your base class?
>
> Not directly, that would be silly.

Silly?  "Explicit is better than implicit"... right?

>> 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.

Ha,  "only the direction reversed".  That little directionality that
you're passing by so blithely is the difference between whether you're
talking about galaxies or atoms.  Please.

The simplicity of Python has seduced you into making an "equivocation"
of sorts.  It's subtle and no one in the field has noticed it.  It
crept in slowly and imperceptively.

>> 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.

They are not necessarily ill-defined.  Keep in mind Python already
chose (way back in 1.x) to arbitrary overwrite the values in a key
collision.  So this problem isn't new.  You've simply adapted to this
limitation without knowing what you were missing.

>>>> 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.

You're just being argumentative.  If there are sets as built-ins, then
{:} is the obvious dict literal, because {} is the obvious one for
set.  You don't need [,] to be the list literal because there is no
simpler list-type.

>>> 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.

I mean, you're suggestions are coming from a "believer", not someone
wanting to understand the limitations of python or whether v3 has
succeeded at achieving its potential.

>>> 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.

Well, wer'e here at junior-high.  It will take some time....
-- 
MarkJ
Tacoma, Washington