Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!ecngs!feeder2.ecngs.de!novso.com!newsfeed.xs4all.nl!newsfeed4.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: <54c07d04$0$13012$c3e8da3$5496439d@news.astraweb.com>
References: <54c07d04$0$13012$c3e8da3$5496439d@news.astraweb.com>
Date: Thu, 22 Jan 2015 05:50:52 +0000
Subject: Re: Python is DOOMED! Again!
From: Nicholas Cole <nicholas.cole@gmail.com>
To: "Steven D'Aprano" <steve+comp.lang.python@pearwood.info>
Content-Type: multipart/alternative; boundary=001a11346fd838b699050d37411d
Cc: "python-list@python.org" <python-list@python.org>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.17949.1421905859.18130.python-list@python.org>
Lines: 104
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:84192

--001a11346fd838b699050d37411d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don't think that Python is doomed. I *do* think that type-hinting is
useful, and Python has borrowed a syntax that is similar to that used in
other languages, so that it is a familiar one to many developers.

It is a stretch to call it intuitive though, either to write or to
read. Personally, I would have favoured a doc string solution. The magic
comments that are part of the current proposal are genuinely intuitive, I
think. The function definition syntax is something to be learned and which
it takes me a little time to process even though I'm getting used to it. I
find that it's still a slight effort to remember which way around the name
of the argument and the type go. I'm sure I've seen one language that does
the oppoosite, and the fraction of a second it takes me to remember is a
tiny friction. There's no doubt, too, that long function definitions
(Python functions tend to have lots of arguments in the real world) are
going to look cluttered, and cluttered by lots of magic punctuation.

So useful, yes. Familiar already to those who use other languages, yes.
Intuitive, no. And there is a linguistic reason for that:

Consider this:

Define function add taking price1, price2, print_error equals true.

Yes, Python wouldn't understand that, but turning it in to a valid
definition requires only a tiny amount of effort.

Type definitions add a whole level of complexity:

Define function add taking the float price1, the float price2, print_error
equals the Boolean true. Make the function return a float.

Converting that into python simply requires more effort: in other words the
gap between what one might say in speech and what the code looks like is
bigger.

The reason for this is that a lot of information is being compressed in to
a small space. In English writing it is usually clearer to avoid long and
complicated sentences with lots of subclauses (even if they make perfect,
logical sense) in favour of shorter ones, and I think there is a parallel
here.

I would have preferred Python to mimic:

Define function add taking price1, the price2, print_error equals true.
Price1 is a float. Price2 is a float. The function returns a float.

But now this is sounding a little like something from Larry Wall, and so I
had better stop!  I wasn't trying to re-litigate the decisions that have
been taken, just to understand the friction.

Just my =C2=A30.2

Nicholas.

--001a11346fd838b699050d37411d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don&#39;t think that Python is doomed. I *do* think that type-hinting is =
useful, and Python has borrowed a syntax that is similar to that used in ot=
her languages, so that it is a familiar one to many developers.=C2=A0<div><=
br></div><div>It is a stretch to call it intuitive though, either to write =
or to read.=C2=A0Personally, I would have favoured a doc string solution. T=
he magic comments that are part of the current proposal are genuinely intui=
tive, I think. The function definition syntax is something to be learned an=
d which it takes me a little time to process even though I&#39;m getting us=
ed to it. I find that it&#39;s still a slight effort to remember which way =
around the name of the argument and the type go.=C2=A0I&#39;m sure I&#39;ve=
 seen one language that does the oppoosite, and the fraction of a second it=
 takes me to remember is a tiny friction. There&#39;s no doubt, too, that l=
ong function definitions (Python functions tend to have lots of arguments i=
n the real world) are going to look cluttered, and cluttered=C2=A0by lots o=
f magic punctuation. =C2=A0</div><div><br></div><div>So useful, yes. Famili=
ar already to those who use other languages, yes. Intuitive, no. And there =
is a linguistic=C2=A0reason for that:=C2=A0</div><div><br></div><div>Consid=
er this:</div><div><br></div><div>Define function add taking price1, price2=
, print_error equals true.=C2=A0</div><div><br></div><div>Yes, Python would=
n&#39;t understand that, but turning it in to a valid definition requires o=
nly a tiny amount of effort.=C2=A0</div><div><br></div><div>Type definition=
s=C2=A0add a whole level of complexity:</div><div><br></div><div>Define fun=
ction add taking=C2=A0the float=C2=A0price1, the float=C2=A0price2, print_e=
rror equals the Boolean true. Make the function return a float.=C2=A0</div>=
<div><br></div>Converting that into python simply requires=C2=A0more effort=
: in other words the gap between what one might=C2=A0say in speech and what=
 the code looks like is bigger.=C2=A0<div><br></div><div>The reason for thi=
s is that a lot of information is being compressed in to a small space. In =
English writing it is usually clearer to avoid long and complicated sentenc=
es with lots of subclauses (even if they make perfect, logical sense)=C2=A0=
in favour of shorter ones, and I think there is a parallel here.=C2=A0</div=
><div><br></div><div>I would have preferred Python to mimic:</div><div><br>=
</div><div><font><span style=3D"background-color:rgba(255,255,255,0)">Defin=
e function add taking=C2=A0<span></span>price1, the price2, print_error equ=
als true. Price1 is a float. Price2 is a float. The function returns a floa=
t. =C2=A0</span></font><br></div><div><br></div><div>But now this is soundi=
ng a little=C2=A0like something from Larry Wall, and so I had better stop!=
=C2=A0 I wasn&#39;t trying to re-litigate the decisions that have been take=
n, just to understand the friction.=C2=A0<br><div><div><br></div>Just my =
=C2=A30.2<div><br></div><div>Nicholas.=C2=A0</div></div></div>

--001a11346fd838b699050d37411d--