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 <ncogh...@gmail.com> wrote: > On 25 September 2016 at 11:55, אלעזר <elaz...@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
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
