Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171105/417eebcd/attachment.html below:
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 5 Nov, 2017, at 9:55 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="">ncoghlan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Python's name resolution rules are already ridiculously complicated,</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">and PEP 563 is proposing to make them *even worse*, purely for the</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">sake of an optional feature primarily of interest to large enterprise</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">users.</span></div></blockquote></div><br class=""><div class="">Solving forward references in type annotations is one of the two explicit goals of the PEP. That alone changes how name resolution works. It sounds like you're -1 on that idea alone?</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">That's enough to leave nested classes as the main problematic case,<br class="">since they can't see each other's attributes by default, and the<br class="">proposed injected locals semantics in PEP 563 don't get this right<br class="">either (they only account for MRO-based name resolution, not lexical<br class="">nesting, even though the PEP claims the latter is expected to work)</blockquote></div><div class=""><br class=""></div><div class="">You're right! I went too far here. I meant to be as compatible as possible with how regular attribute access works for nested classes. Originally I didn't want to support any locals at all for simplicity. I was convinced this is important (documented in "Rejected ideas") but overdid the example.</div><div class=""><br class=""></div><div class="">Since your example that illustrates the problem shows that those things fail for regular attribute lookup, too, that can be simply fixed in the PEP. I did that here:</div><div class=""><a href="https://github.com/ambv/static-annotations/blob/master/pep-0563.rst#backwards-compatibility" class="">https://github.com/ambv/static-annotations/blob/master/pep-0563.rst#backwards-compatibility</a></div><div class=""><br class=""></div><div class="">Note that I am still including the "def method(self) -> D.field2:" example as valid as including a class' own name in the locals() chain map provided by get_type_hints() is going to be trivial. In fact, I think I'll add this to get_type_hints() independently of this PEP since users of string literal forward references probably don't expect it to fail for nested classes.</div><div class=""><br class=""></div><div class="">- Å</div></body></html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4