If type annotations are treated like implicit lambdas, then that's a first step to something similar to Lisp's "special forms". A full generalization of that would allow, for example, logging.debug to not evaluate its args unless debugging is turned on (I use a logging.debug wrapper that allows lambdas as args, and evaluates them if debugging is turned on). Maybe a better question is whether we want "special forms" in Python. It complicates some things but simplifies others. But things that satisfy Lisp programmers might not make Python programmers happy. ;) On 4 November 2017 at 09:42, Guido van Rossum <guido at python.org> wrote: > 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. > > On Sat, Nov 4, 2017 at 6:51 AM, Nick Coghlan <ncoghlan at gmail.com> wrote: > >> On 4 November 2017 at 00:40, Guido van Rossum <guido at python.org> wrote: >> > IMO the inability of referencing class-level definitions from >> annotations on >> > methods pretty much kills this idea. >> >> If we decided we wanted to make it work, I think the key runtime >> building block we would need is a new kind of cell reference: an >> IndirectAttributeCell. >> >> Those would present the same interface as a regular nonlocal cell (so >> it could be stored in __closure__ just as regular cells are, and >> accessed the same way when the function body is executed), but >> internally it would hold two references: >> >> - one to another cell object (__class__ for this use case) >> - an attribute name on the target object that get/set/del operations >> on the indirect cell's value should affect >> >> As Python code: >> >> class IndirectAttributeCell: >> def __new__(cls, cell, attr): >> self._cell = cell >> self._attr = attr >> >> @property >> def cell_contents(self): >> return getattr(self._cell.cell_contents, self._attr) >> >> @cell_contents.setter >> def cell_contents(self, value): >> setattr(self._cell.cell_contents, self._attr, value) >> >> @cell_contents.deleter >> def cell_contents(self): >> delattr(self._cell.cell_contents, self._attr) >> >> The class body wouldn't be able to evaluate the thunks (since >> `__class__` wouldn't be set yet), but `__init_subclass__` >> implementations could, as could class decorators. >> >> It would require some adjustment in the compiler as well (in order to >> pass the class level attribute definitions down to these implicitly >> defined scopes as a new kind of accessible external namespace during >> the symbol analysis pass, as well as to register the use of >> "__class__" if one of the affected names was referenced), but I think >> it would work at least at a technical level (by contrast, every other >> idea I came up with back when I was working on the list comprehension >> change was sufficiently flawed that it fell apart within a few hours >> of starting to tinker with the idea). >> >> As an added bonus, we could potentially also extend the same >> permissive name resolution semantics to the implicit scopes used in >> comprehensions, such that it was only the explicitly defined scopes >> (i.e. lambda expressions, function definitions, and nested classes) >> that lost implicit access to the class level variables. >> >> Cheers, >> Nick. >> >> P.S. If we subsequently decided to elevate expression thunks to a >> first class language primitive, they shouldn't need any further >> semantic enhancements beyond that one, since the existing scoping >> rules already give the desired behaviour at module and function scope. >> >> -- >> Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia >> > > > > -- > --Guido van Rossum (python.org/~guido) > > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ > pludemann%40google.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171104/d10c9dd0/attachment.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