
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