<div dir="ltr">I'm very worried about trying to come up with a robust implementation of this in under 12 weeks. By contrast, the stringification that Åukasz is proposing feels eminently doable.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 4, 2017 at 6:51 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4 November 2017 at 00:40, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> IMO the inability of referencing class-level definitions from annotations on<br>
> methods pretty much kills this idea.<br>
<br>
</span>If we decided we wanted to make it work, I think the key runtime<br>
building block we would need is a new kind of cell reference: an<br>
IndirectAttributeCell.<br>
<br>
Those would present the same interface as a regular nonlocal cell (so<br>
it could be stored in __closure__ just as regular cells are, and<br>
accessed the same way when the function body is executed), but<br>
internally it would hold two references:<br>
<br>
- one to another cell object (__class__ for this use case)<br>
- an attribute name on the target object that get/set/del operations<br>
on the indirect cell's value should affect<br>
<br>
As Python code:<br>
<br>
  class IndirectAttributeCell:<br>
    def __new__(cls, cell, attr):<br>
      self._cell = cell<br>
      self._attr = attr<br>
<br>
    @property<br>
    def cell_contents(self):<br>
      return getattr(self._cell.cell_<wbr>contents, self._attr)<br>
<br>
    @cell_contents.setter<br>
    def cell_contents(self, value):<br>
      setattr(self._cell.cell_<wbr>contents, self._attr, value)<br>
<br>
    @cell_contents.deleter<br>
    def cell_contents(self):<br>
      delattr(self._cell.cell_<wbr>contents, self._attr)<br>
<br>
The class body wouldn't be able to evaluate the thunks (since<br>
`__class__` wouldn't be set yet), but `__init_subclass__`<br>
implementations could, as could class decorators.<br>
<br>
It would require some adjustment in the compiler as well (in order to<br>
pass the class level attribute definitions down to these implicitly<br>
defined scopes as a new kind of accessible external namespace during<br>
the symbol analysis pass, as well as to register the use of<br>
"__class__" if one of the affected names was referenced), but I think<br>
it would work at least at a technical level (by contrast, every other<br>
idea I came up with back when I was working on the list comprehension<br>
change was sufficiently flawed that it fell apart within a few hours<br>
of starting to tinker with the idea).<br>
<br>
As an added bonus, we could potentially also extend the same<br>
permissive name resolution semantics to the implicit scopes used in<br>
comprehensions, such that it was only the explicitly defined scopes<br>
(i.e. lambda expressions, function definitions, and nested classes)<br>
that lost implicit access to the class level variables.<br>
<br>
Cheers,<br>
Nick.<br>
<br>
P.S. If we subsequently decided to elevate expression thunks to a<br>
first class language primitive, they shouldn't need any further<br>
semantic enhancements beyond that one, since the existing scoping<br>
rules already give the desired behaviour at module and function scope.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Nick Coghlan  |  <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>  |  Brisbane, Australia<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>