[Python-ideas] Delay evaluation of annotations

[אלעזר]

Thanks for the references. I will read them.

In general, I am against magic in code. I am for magic in specification,
with appropriate hints (e.g. the explicit name in the decorator, as pointed
to me by Chris) and with taste. The most important part about specification
is being naturally understood by human. The second most important is being
understood by tools. What's not important: being understood by the
interpreter.

CPython as a reference implementation has a very, very specific behavior,
changing at every minor release. Of course not every tiny detail of this
behavior is promised. It is understood by users that e.g. they cannot rely
on their code taking 0.6ms to execute in such and such settings, since
real-time conדtraints are not promised even if some part of some version of
CPython happens to run this fast deterministically.
The implementation specifies the behavior, except when common sense or
documentation says otherwise. Am I wrong?

On Sun, Sep 25, 2016 at 7:07 PM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 25 September 2016 at 11:55, אלעזר <elazarg at gmail.com> wrote:
> > Nick, I have read your blog post about the high bar required for
> > compatibility break, and I follow this mailing list for a while. So I
> agree
> > with the reasoning (from my very, very little experience); I only want to
> > understand where is this break of compatibility happen, because I can't
> see
> > it.
>
> This code works as a doctest today:
>
>     >>> def func(a: "Expected output"):
>     ...     pass
>     ...
>     >>> print(func.__annotations__["a"])
>     Expected output
>
> Any change that breaks that currently valid doctest is necessarily a
> compatibility break for the way annotations are handled at runtime. It
> doesn't matter for that determination how small the change to fix the
> second command is, it only matters that it *would* have to change in
> some way.
>
> In particular, switching to delayed evaluation would break all the
> introspection tools that currently read annotations at runtime, both
> those in the standard library (like inspect.signature() and pydoc),
> and those in third party tools (like IDEs).
>

But my intention is that this code will work just fine. As is any other
access using __annotations__ or any existing API. The only visible change
should be that of expressions with visible side effect, so this is the kind
of break I am looking for. The following will break

def foo(a: print(1)): pass

But nobody (yet) claimed it to be a reasonable example of code we don't
want to break. There can hardly be any, since any side effect can be placed
right before the definition. So just like star-imports that are broken
every time a function is added to some library, IIUC, you don't care about
breaking them, because they are strongly and explicitly discouraged.

Elazar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160925/a232fe43/attachment-0001.html>