<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 13, 2014 at 3:29 PM, Christian Heimes <span dir="ltr"><<a href="mailto:christian@python.org" target="_blank">christian@python.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 13.08.2014 21:44, Guido van Rossum wrote:<br>
> Yesterday afternoon I had an inspiring conversation with Bob Ippolito<br>
> (man of many trades, author of simplejson) and Jukka Lehtosalo (author<br>
> of mypy: <a href="http://mypy-lang.org/" target="_blank">http://mypy-lang.org/</a>). Bob gave a talk at EuroPython about<br>
> what Python can learn from Haskell (and other languages); yesterday he<br>
> gave the same talk at Dropbox. The talk is online<br>
> (<a href="https://ep2014.europython.eu/en/schedule/sessions/121/" target="_blank">https://ep2014.europython.eu/en/schedule/sessions/121/</a>) and in broad<br>
> strokes comes down to three suggestions:<br>
><br>
>   (a) Python should adopt mypy's syntax for function annotations<br>
>   (b) Python's use of mutabe containers by default is wrong<br>
>   (c) Python should adopt some kind of Abstract Data Types<br>
<br>
</div>I was at Bob's talk during EP14 and really liked the idea. A couple of<br>
colleagues and other attendees also said it's a good and useful<br>
proposal. I also like your proposal to standardize the type annotations<br>
first without a full integration of mypy.<br>
<br>
In general I'm +1 but I like to discuss two aspects:<br>
<br>
1) I'm not keen with the naming of mypy's typing classes. The visual<br>
distinction between e.g. dict() and Dict() is too small and IMHO<br>
confusing for newcomers. How about an additional 'T' prefix to make<br>
clear that the objects are referring to typing objects?<br>
<br>
  from typing import TList, TDict<br>
<br>
  def word_count(input: TList[str]) -> TDict[str, int]:<br>
      ...<br></blockquote><div><br></div><div>Eeewwwww. That's way too Pascal-ish.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) PEP 3107 only specifies arguments and return values but not<br>
exceptions that can be raised by a function. Java has the "throws"<br>
syntax to list possible exceptions:<br>
<br>
 public void readFile() throws IOException {}<br>
<br>
May I suggest that we also standardize a way to annotate the exceptions<br>
that can be raised by a function? It's a very useful piece of<br>
information and commonly requested information on the Python user<br>
mailing list. It doesn't have to be a new syntax element, a decorator in<br>
the typing module would suffice, too. For example:<br>
<br>
  from typing import TList, TDict, raises<br>
<br>
  @raises(RuntimeError, (ValueError, "is raised when input is empty"))<br>
  def word_count(input: TList[str]) -> TDict[str, int]:<br>
      ...<br></blockquote><div><br></div><div>That was a disaster in C++. It's confusing, especially since Python uses exceptions more than most other languages do.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
Regards,<br>
Christian<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Ryan<div><div>If anybody ever asks me why I prefer C++ to C, my answer will be simple: "It's becauseslejfp23(@#Q*(E*EIdc-SEGFAULT. Wait, I don't think that was nul-terminated."</div>

</div><div><br></div></div>
</div></div>