Showing content from http://mail.python.org/pipermail/python-dev/attachments/20171108/e94aa3a2/attachment.html below:
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 8, 2017 at 5:49 PM, 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 8 November 2017 at 16:24, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> I also don't like the idea that there's nothing you can do with a thunk<br>
> besides calling it -- you can't meaningfully introspect it (not without<br>
> building your own bytecode interpreter anyway).<br>
<br>
</span>Wait, that wasn't what I was suggesting at all - with thunks exposing<br>
their code object the same way a function does (i.e. as a `__code__`<br>
attribute), the introspection functions in `dis` would still work on<br>
them, so you'd be able to look at things like which variable names<br>
they referenced, thus granting the caller complete control over *how*<br>
they resolved those variable names (by setting them in the local<br>
namespace passed to the call).<br></blockquote><div><br></div><div>I understood that they would be translated to `lambda: <expr>`. It seems you have a slightly more complex idea but if you're suggesting introspection through dis, that's too complicated for my taste.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is why they'd have interesting potential future use cases as<br>
general purpose callbacks - every local, nonlocal, global, and builtin<br>
name reference would implicitly be an optional parameter (or a<br>
required parameter if the name couldn't be resolved as a nonlocal,<br>
global, or builtin).<span class=""><br></span></blockquote><div><br></div><div>Yeah, but that's scope creep for PEP 563. Åukasz and I are interested in gradually restricting the use of annotations to static typing with an optional runtime component. We're not interested in adding different use cases. (We're committed to backwards compatibility, but only until 4.0, with a clear deprecation path.)<br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Using an AST instead of a string is also undesirable -- the AST changes in<br>
> each release, and the usual strong compatibility guarantees don't apply<br>
> here. And how are you going to do anything with it? If you've got a string<br>
> and you want an AST node, it's one call away. But if you've got an AST node<br>
> and you want either a string *or* the object to which that string would<br>
> evaluate, you've got a lot of work to do. Plus the AST takes up a lot more<br>
> space than the string, and we don't have a way to put an AST in a bytecode<br>
> file. (And as Inada-san pointed out a thunk *also* takes up more space than<br>
> a string.)<br>
><br>
> Nick, please don't try to save the thunk proposal by carefully dissecting<br>
> every one of my objections. That will just prolong its demise.<br>
<br>
</span>Just the one objection, since you seem to be rejecting something I<br>
didn't suggest (i.e. adding an opaque callable type that the dis and<br>
inspect modules didn't understand). I agree that would be a bad idea,<br>
but it's also not what I was suggesting we do.<br></blockquote><div><br></div><div>I did not assume totally opaque -- but code objects are not very introspection friendly (and they have no strong compatibility guarantees).<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Instead, thunks would offer all the same introspection features as<br>
lambda expressions do, they'd just differ in the following ways:<br>
<br>
* the parameter list on their code objects would always be empty<br>
* the parameter list for their __call__ method would always be "ns=None"<br>
* they'd be compiled without CO_OPTIMIZED (the same as a class namespace)<br>
* they'd look up their closure references using LOAD_CLASSDEREF (the<br>
same as a class namespace)<br></blockquote><div><br></div><div>I don't understand the __call__ with "ns-None" thing but I don't expect it matters.<br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That said, even without a full-fledged thunk based solution to<br>
handling lexical scoping I think there's a way to resolve the nested<br>
class problem in PEP 563 that works for both explicitly and implicitly<br>
quoted strings, while still leaving the door open to replacing<br>
implicitly quoted strings with thunks at a later date: stating that<br>
*if* users want such nested references to be resolvable at runtime,<br>
they need to inject a runtime reference to the outermost class into<br>
the inner class namespace.<br>
<br>
That is, if you want to take:<br>
<span class=""><br>
  class C:<br>
    field = 1<br>
    class D:<br>
      def method(a: C.field):<br>
</span>Â Â Â Â Â Â Â Â ...<br>
<br>
and move it inside a function, that would actually look like:<br>
<br>
  def f():<br>
<span class="">Â Â Â Â class C:<br>
      field = 1<br>
      class D:<br>
        def method(a: C.field):<br>
</span>Â Â Â Â Â Â Â Â Â Â ...<br>
    C.D.C = C # Make annotations work at runtime<br>
    return f<br>
<br>
That leaves the door open to a future PEP that proposes thunk-based<br>
annotations as part of proposing thunks as a new low level delayed<br>
evaluation primitive.<br></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Sorry, that's not a door I'd like to leave open.<br></div><div class="gmail_extra"><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></div>
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