On Thu, Apr 10, 2014 at 9:05 AM, Barry Warsaw <barry@python.org> wrote:
Nice PEP; I'm sorry we didn't get a chance to discuss it at the language summit.
Yeah, I didn't even bother mentioning it because I didn't have any performance numbers yet. I Hope to have some today, however.
Since this is touching a fundamental and common aspect of the language, I think a lot of analysis has to be done for both performance and semantics if the feature is opt-out.
The proposal currently doesn't even involve opting anything. :) Opt-out is my fallback proposal in case performance has significant change when "people do crazy things".
People do crazy things and even small performance hits add up. The use cases are valid but rare I submit, so I think most Python code doesn't care. Thus I'd lean toward an opt-in approach.
The problem is that opt-in causes all sorts of complication due to some wrapper factories like functools.partial and many decorators. They take **kwargs, and then unpack them in the wrapped call, so the wrapper definition would have to know how to opt-in when the wrappee has opted in. Andrew Barnert and I discussed this at length in the previous python-ideas thread. My conclusion was that we should avoid opt-in if at all possible.
Perhaps a transition period makes sense. Add both opt-in and opt-out decorators, implement opt-in by default for Python 3.5 with a -X option to switch it to opt-out.
If we could work out the opt-in complications that could work. However, I just don't think opt-in will be worth the trouble. That said, right now we're mostly just guessing about the performance impact. :) I hope to have a better answer to that question soon. -eric