Home Original page

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

אלעזר elazarg at gmail.com
Fri Jul 8 06:53:25 EDT 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 at python.org>:

> Send Python-ideas mailing list submissions to
>         python-ideas at 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 at python.org
>
> You can reach the person managing the list at
>         python-ideas-owner at 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 at gmail.com>
> Cc: python-ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Add an option that allow check Type Hints
>         in runtime
> Message-ID:
>         <CAPTjJmpgFaxqd7gU407u5c+tURayv3OkvdTJ8RH7N=
> KbkXXi3Q at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Jul 8, 2016 at 6:19 PM, Ma Lin <animalize81 at 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 at gmail.com>
> To: Chris Angelico <rosuav at gmail.com>
> Cc: python-ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Add an option that allow check Type Hints
>         in runtime
> Message-ID:
>         <
> CACac1F-+Si-uXwce2CKPiyM576MX7G+Cp4u8n-TXBO_89UTbdQ at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On 8 July 2016 at 09:30, Chris Angelico <rosuav at gmail.com> wrote:
> > On Fri, Jul 8, 2016 at 6:19 PM, Ma Lin <animalize81 at 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 at gmail.com>
> Cc: python-ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Add an option that allow check Type Hints
>         in runtime
> Message-ID:
>         <CAPTjJmp_=6PFfnKEeboGuXm=
> ffM+NB_ysUPNQxvXJUm4UtbFZg at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Jul 8, 2016 at 6:50 PM, Paul Moore <p.f.moore at 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 at gmail.com>
> Cc: python-ideas <python-ideas at python.org>
> Subject: Re: [Python-ideas] Add an option that allow check Type Hints
>         in runtime
> Message-ID:
>         <
> CAPTjJmrJstnRzEK48Kj7gOZDi5kkfBPrUCNYQqGds3qje-ZFbA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Fri, Jul 8, 2016 at 7:02 PM, Chris Angelico <rosuav at 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 at hotmail.com>
> To: "python-ideas at python.org" <python-ideas at python.org>
> Subject: Re: [Python-ideas] Add an option that allow check Type Hints
>         in runtime
> Message-ID:
>         <
> PS1PR06MB1099F602EB64A07AAC2063F0B63C0 at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
>
>
> ------------------------------
>
> End of Python-ideas Digest, Vol 116, Issue 12
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160708/242afd2a/attachment-0001.html>
More information about the Python-ideas mailing list