<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 12, 2017, at 5:38 AM, Ivan Levkivskyi <<a href="mailto:levkivskyi@gmail.com" class="">levkivskyi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class="">In principle, I like this idea, this will save some keystrokes<br class="">and will make annotated code more "beautiful". But I am quite worried about the backwards<br class=""></div>compatibility. One possible idea would be to use __future__ import without a definite<br class="">deprecation plan.</div></div></div></blockquote><div><br class=""></div><div>This is not a viable strategy since __future__ is not designed to be a feature toggle but rather to be a gradual introduction of an upcoming breaking change.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">If people will be fine with using typing.get_type_hints<br class="">(btw this is already the preferred way instead of directly accessing __annotations__,<br class="">according to PEP 526 at least) then we could go ahead with deprecation.</div></div></div></blockquote><div><br class=""></div><div>As you're pointing out, people already <b class="">have to</b> use `typing.get_type_hints()`, otherwise they are already failing evaluation of existing forward references. Accessing __annotations__ directly in this context is a bug today.</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Also I really like Yury's idea of dynamic mapping</div></div></div></blockquote></div><div><br class=""></div><div>I responded to his idea under his post.</div><div><br class=""></div><div>- Å</div></body></html>