<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 23 Jan 2017 at 04:27 INADA Naoki <<a href="mailto:songofacandy@gmail.com">songofacandy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jan 23, 2017 at 8:33 PM, Victor Stinner<br class="gmail_msg">
<<a href="mailto:victor.stinner@gmail.com" class="gmail_msg" target="_blank">victor.stinner@gmail.com</a>> wrote:<br class="gmail_msg">
> 2017-01-23 12:25 GMT+01:00 INADA Naoki <<a href="mailto:songofacandy@gmail.com" class="gmail_msg" target="_blank">songofacandy@gmail.com</a>>:<br class="gmail_msg">
>> I gave advice to use 'List[User]' instead of List[User] to the team of<br class="gmail_msg">
>> the project,<br class="gmail_msg">
>> if the team think RAM usage or boot speed is important.<br class="gmail_msg">
><br class="gmail_msg">
> I would prefer a Python option (ex: "-o noannotation" command line<br class="gmail_msg">
> option) to opt-out annotations rather than having to write annotations<br class="gmail_msg">
> in strings, which is IMHO more "ugly".<br class="gmail_msg"></blockquote><div><br></div><div>So basically the equivalent of -OO for docstrings? Maybe this can be the final motivator for some of us to come up with a design to generalize -O or something as it keeps coming up.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br class="gmail_msg">
> Victor<br class="gmail_msg">
<br class="gmail_msg">
Personally speaking, I hope annotations are just static hint, and<br class="gmail_msg">
makes zero overhead at runtime.<br class="gmail_msg">
(startup time, memory consumption, and execution speed).<br class="gmail_msg"></blockquote><div><br></div><div>Local variable annotations are nothing but info in the AST. Parameter annotations and class annotations are stored on their respective objects so there's memory usage from that and the construction of them at object creation time, but that's it (e.g. the cost of creating func.__annotations__ when the function object is created is all you pay for performance-wise). And using strings will make those introspective attributes difficult to use, hence why I don't think people have said to do that everywhere.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Anyway, many users are starting to use typing, for code completion or<br class="gmail_msg">
static checking.<br class="gmail_msg">
And very few user noticed it affects to performance of `isinstance(x,<br class="gmail_msg">
collections.Sequence)`.<br class="gmail_msg">
Python 3.7 may be too slow to help them.<br class="gmail_msg">
Can't we skip abc registration of typing.List[MyClass] completely?<br class="gmail_msg">
<br class="gmail_msg">
I'm sorry if it's silly idea.  I don't know about background of<br class="gmail_msg">
current typing.py design. And I<br class="gmail_msg">
don't use abc much too.</blockquote><div><br></div><div>Since isinstance() checks are expected to be rare I don't think anyone has worried too much about the performance beyond the initial work to introduce ABCs and __instancecheck__.</div></div></div>