Mailman 3 Re: [Python-ideas] Python-ideas Digest, Vol 116, Issue 12 - Python-ideas

8 Jul 2016

      Function definition can also be changed inside the interpreter, effectively
doing the same work as tge interpreter. The parser can add implicit
decorator too.

This raises a different approach: adding a module decorator, allowing such
implicit decorations accross module functions. Has it been discussed
before?

בתאריך יום ו׳, 8 ביול' 2016, 12:18, מאת ‏<python-ideas-request@python.org>:
...
Send Python-ideas mailing list submissions to
        python-ideas@python.org
To subscribe or unsubscribe via the World Wide Web, visit
        https://mail.python.org/mailman/listinfo/python-ideas
or, via email, send a message with subject or body 'help' to
        python-ideas-request@python.org
You can reach the person managing the list at
        python-ideas-owner@python.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-ideas digest..."
Today's Topics:
1. Re: Add an option that allow check Type Hints in runtime
      (Chris Angelico)
   2. Re: Add an option that allow check Type Hints in runtime
      (Paul Moore)
   3. Re: Add an option that allow check Type Hints in runtime
      (Chris Angelico)
   4. Re: Add an option that allow check Type Hints in runtime
      (Chris Angelico)
   5. Re: Add an option that allow check Type Hints in runtime (Ma Lin)
----------------------------------------------------------------------
Message: 1
Date: Fri, 8 Jul 2016 18:30:52 +1000
From: Chris Angelico <rosuav@gmail.com>
Cc: python-ideas <python-ideas@python.org>
Subject: Re: [Python-ideas] Add an option that allow check Type Hints
        in runtime
Message-ID:
        <CAPTjJmpgFaxqd7gU407u5c+tURayv3OkvdTJ8RH7N=
KbkXXi3Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 8, 2016 at 6:19 PM, Ma Lin <animalize81@hotmail.com> wrote:
...
I mean real check by the interpreter, not an '__annotations__' attribute.
And I just had a look, mypy is a static checker, without actually running
the code.
My thought is modifying CALL_FUNCTION and RETURN_VALUE of the
interpreter,
so that allow them to check in each function calling when option enalbed.
Cite a case:
def fun(a: str, b: int) -> int:
    return len(a) + b
fun('arg1', 'arg2')
Whit the option and run this code, the interpreter will give an error
prompt:
    Type of argument b is wrong. (or something like this)
This is very useful for development and debugging.
You should still be able to do it without changing the core interpreter.
def enforce_types(func):
    @functools.wraps(func)
    def wrapped(*args, **kw):
        if not args_valid(args, kw, func.__annotations__):
            raise TypeError
        ret = func(*args, **kw)
        if not type_valid(ret, func.__annotations__["return"]):
            raise TypeError
    return wrapped
@enforce_types
def fun(a: str, b: int) -> int:
    return len(a) + b
fun('arg1', 'arg2')
Now all you have to do is write the type_valid function (takes an
object and an annotation, returns True if it matches) and args_valid
(takes the positional and keyword args, pairs them up against the
function's params, and returns True if all(type_valid(...)) for the
args). The only benefit of hacking the interpreter core for this is
that you'd save the hassle of pairing up positional/keyword args
against the parameters.
ChrisA
------------------------------
Message: 2
Date: Fri, 8 Jul 2016 09:50:53 +0100
From: Paul Moore <p.f.moore@gmail.com>
To: Chris Angelico <rosuav@gmail.com>
Cc: python-ideas <python-ideas@python.org>
Subject: Re: [Python-ideas] Add an option that allow check Type Hints
        in runtime
Message-ID:
        <
CACac1F-+Si-uXwce2CKPiyM576MX7G+Cp4u8n-TXBO_89UTbdQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On 8 July 2016 at 09:30, Chris Angelico <rosuav@gmail.com> wrote:
...
On Fri, Jul 8, 2016 at 6:19 PM, Ma Lin <animalize81@hotmail.com> wrote:
...
I mean real check by the interpreter, not an '__annotations__'
attribute.
And I just had a look, mypy is a static checker, without actually
running
the code.
My thought is modifying CALL_FUNCTION and RETURN_VALUE of the
interpreter,
so that allow them to check in each function calling when option
enalbed.
[...]
Now all you have to do is write the type_valid function (takes an
object and an annotation, returns True if it matches) and args_valid
(takes the positional and keyword args, pairs them up against the
function's params, and returns True if all(type_valid(...)) for the
args). The only benefit of hacking the interpreter core for this is
that you'd save the hassle of pairing up positional/keyword args
against the parameters.
Just to clarify for the OP - the reason you're getting pushback on
making this a built in interpreter function is twofold - first, an
external facility could be used *now*, and would not need to be
limited to Python 3.6+, and second, adding checks to the function call
protocol is not free, and would therefore affect not just the minority
of people who want to add checks for debugging, but also all other
users (which include people for whom Python's performance is a key
issue). The Python interpreter's function calling process is known to
be slower than (some) people would like, and making it slower - even
marginally - isn't something we would want to do lightly.
With the ability to use external static analyzers like mypy, as well
as the possibility of writing custom solutions like Chris described
above, people wanting such checks have a number of options already,
and so the cost of adding the feature to the interpreter (and possibly
the language - do you see this as a CPython implementation detail, or
would you expect it to be a language-level facility, so other Python
implementations such as PyPy and Jython would be expected to have it
as well?) needs to be justified.
Personally, I'd view this feature as an interesting addition, but not
something I'd use myself, and so I'm inclined towards the "why should
I pay for something I won't use?" position.
Paul
------------------------------
Message: 3
Date: Fri, 8 Jul 2016 19:02:21 +1000
From: Chris Angelico <rosuav@gmail.com>
Cc: python-ideas <python-ideas@python.org>
Subject: Re: [Python-ideas] Add an option that allow check Type Hints
        in runtime
Message-ID:
        <CAPTjJmp_=6PFfnKEeboGuXm=
ffM+NB_ysUPNQxvXJUm4UtbFZg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 8, 2016 at 6:50 PM, Paul Moore <p.f.moore@gmail.com> wrote:
...
Just to clarify for the OP - the reason you're getting pushback on
making this a built in interpreter function is twofold - first, an
external facility could be used *now*, and would not need to be
limited to Python 3.6+, and second, adding checks to the function call
protocol is not free, and would therefore affect not just the minority
of people who want to add checks for debugging, but also all other
users (which include people for whom Python's performance is a key
issue). The Python interpreter's function calling process is known to
be slower than (some) people would like, and making it slower - even
marginally - isn't something we would want to do lightly.
Exactly. The main reason IMO is the first one - you can add this
checker to any Python 3 program, rather than wait for it to get coded,
debugged, and shipped.
Oh, and you can easily have a flag that disables checking for performance:
if no_type_checks:
    def enforce_types(func):
        return func
Now your decorator does nothing, and there is literally ZERO run-time
cost (the only cost is a single cheap check when the function is
defined, which usually means on module import), closures aside. That
wouldn't be possible with a core interpreter change, unless it's made
a compile-time option *for the interpreter* - something like
"./configure --with-annotations-enforced" - and then you run python3.6
for the fast one, or python3.6tc for the type-checking one. That would
be a pain.
ChrisA
------------------------------
Message: 4
Date: Fri, 8 Jul 2016 19:05:44 +1000
From: Chris Angelico <rosuav@gmail.com>
Cc: python-ideas <python-ideas@python.org>
Subject: Re: [Python-ideas] Add an option that allow check Type Hints
        in runtime
Message-ID:
        <
CAPTjJmrJstnRzEK48Kj7gOZDi5kkfBPrUCNYQqGds3qje-ZFbA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Fri, Jul 8, 2016 at 7:02 PM, Chris Angelico <rosuav@gmail.com> wrote:
...
Now your decorator does nothing, and there is literally ZERO run-time
cost (the only cost is a single cheap check when the function is
defined, which usually means on module import), closures aside. That
wouldn't be possible with a core interpreter change...
I really shouldn't say impossible. Literally the moment I clicked
Send, I thought of a way it could be done with minimal run-time cost:
just create a completely separate opcode for "type-checked call". I
don't think that would materially slow down the regular call
operation. As a bonus, any functions that don't have annotations could
use the normal call opcode, so they wouldn't be slowed down.
But the main point is, this would all entail additional complexity
inside CPython, where the decorator method keeps the complexity in
your application - and doesn't need nearly as much of it. The one
advantage that CPython has is, as mentioned, the matching of arguments
to parameters; maybe that could be provided in functools somewhere?
ChrisA
------------------------------
Message: 5
Date: Fri, 8 Jul 2016 09:17:56 +0000
From: Ma Lin <animalize81@hotmail.com>
To: "python-ideas@python.org" <python-ideas@python.org>
Subject: Re: [Python-ideas] Add an option that allow check Type Hints
        in runtime
Message-ID:
        <
PS1PR06MB1099F602EB64A07AAC2063F0B63C0@PS1PR06MB1099.apcprd06.prod.outlook.com
...
Content-Type: text/plain; charset="Windows-1252"
I see, Chris' decorator is amazing, I didn't think that way.
I mean add an runtime option, not a build option, it can be only enabled
in development/debugging:
     python -tc a.py
Without the option, the interpreter just ignores Type Hints:
     python a.py
Anyway, I just throw an idea to here. Greet to all of you for bring
Python to me.
------------------------------
Subject: Digest Footer
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
------------------------------
End of Python-ideas Digest, Vol 116, Issue 12
*********************************************

Re: [Python-ideas] Python-ideas Digest, Vol 116, Issue 12

אלעזר

tags

participants (1)