Mailman 3 July 2016 - Python-ideas

Smoothing transition to Python 3
by Neil Schemenauer July 10, 2016

July 10, 2016

I'm nearly finished porting a decently size application from Python 2 to Python 3. It has been a lot of work. I am dubious as to whether the port was really the best use of time. I can imagine there is still millions, possibly billions of lines of Python 2 code that has not yet been converted. Further, my guess is the lines of Python 2 code are still growing faster than the lines of Python 3 compatible code. IMHO, we need to do better in making it easier for people to port code. Here is a … [View More]

30 68

Add an option that allow check Type Hints in runtime
by Ma Lin July 9, 2016

July 9, 2016

Hi, all, Is it possible to add an option that allow check Type Hints in runtime? So that I can enable dynamic type checking when debugging. And disable it in final deploy, no performance lose. regards.

7 13

Re: [Python-ideas] Python-ideas Digest, Vol 116, Issue 12
by אלעזר July 8, 2016

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

1 0

should `dict` supply a default `__missing__` implementation?
by Matt Gilson July 6, 2016

July 6, 2016

The following code raises an `AttributeError`: >>> class D(dict): ... def __missing__(self, k): ... super(D, self).__missing__(k) ... >>> d = D() >>> d['key'] Traceback (most recent call last): File "<stdin>", line 1, in <module> File "<stdin>", line 3, in __missing__ AttributeError: 'super' object has no attribute '__missing__' I find this behavior to be a little bit odd as I would have expected the default implementation to have … [View More]

8 20

__enter__ and __exit__ on generators
by Nathaniel Smith July 6, 2016

July 6, 2016

Hi all, This might be too trivial for python-ideas even, but... I recently stumbled slightly over the way that generators define a close method (the one that injects a GeneratorExit), but don't directly implement the context manager protocol. So if you want a generator's internal resources to be cleaned up promptly, you can't write with genfunc() as it: for obj in it: ... but instead have to write with contextlib.closing(genfunc()) as it: for obj in it: ..… [View More]

4 3

Unpacking a dict
by Michael Selik July 5, 2016

July 5, 2016

Python's iterable unpacking is what Lispers might call a destructuring bind. py> iterable = 1, 2, 3, 4, 5 py> a, b, *rest = iterable py> a, b, rest (1, 2, (3, 4, 5)) Clojure also supports mapping destructuring. Let's add that to Python! py> mapping = {"a": 1, "b": 2, "c": 3} py> {"a": x, "b": y, "c": z} = mapping py> x, y, z (1, 2, 3) py> {"a": x, "b": y} = mapping Traceback: ValueError: too many keys to unpack This will be … [View More]

32 131

documentation for python3 super()
by Barry Scott July 4, 2016

July 4, 2016

I have read the python3.5 docs for super() and https://rhettinger.wordpress.com/2011/05/26/super-considered-super/. Between the two sources I still have no clear idea of what super() will do and why it will doe what it does. I hope to get feedback that can be used as the basis to update the python docs. For single inheritance the use of super() does not seem to have any surprises. But in the case of a class with multiple-inheritance more then 1 function may be called by 1 call to super(). … [View More]

5 7