<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Jul 2, 2017 at 2:16 PM, Steven D'Aprano <span dir="ltr"><<a href="mailto:steve@pearwood.info" target="_blank">steve@pearwood.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Jun 24, 2017 at 10:42:19PM +0300, Koos Zevenhoven wrote:<br>
<br>
[...]<br>
<span class="">> Clearly, there needs to be some sort of distinction between runtime<br>
> classes/types and static types, because static types can be more precise<br>
> than Python's dynamic runtime semantics.<br>
<br>
</span>I think that's backwards: runtime types can be more precise than static<br>
types. Runtime types can make use of information known at compile time<br>
*and* at runtime, while static types can only make use of information<br>
known at compile time. </blockquote><div><br><br><div style="font-family:monospace,monospace" class="gmail_default">​This is not backwards -- just a different interpretation of the same situation. In fact, the problem is that 'type' already means too many different things. Clarity of terminology for a concept helps a lot in making the concept itself simpler and easier for both the designers and the users.<br><br></div><div style="font-family:monospace,monospace" class="gmail_default">This is analogous to the problem in English language that the verb 'argue' does not have a single meaning. Sometimes the concepts of an argument and a productive discussion get mixed up, and people who want to discuss productively just end up going away because others are turning the discussion into an argument.<br><br></div><div style="font-family:monospace,monospace" class="gmail_default">-- Koos<br></div><br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>