On 15.10.2017 07:13, Nick Coghlan wrote:
On 15 October 2017 at 14:53, M.-A. Lemburg <mal@egenix.com> wrote:
The behavior of also deferring the context to time of execution should be the non-standard form to not break this intuition, otherwise debugging will be a pain and writing fully working code would be really hard in the face of changing contexts (e.g. say decimal rounding changes in different parts of the code).
No, it really wouldn't, since "the execution context is the context that's active when the code is executed" is relatively easy to understand based entirely on the way functions, methods, and other forms of delayed execution work (including iterators).
"The execution context is the context that's active when the code is executed, *unless* the code is in a generator, in which case, it's the context that was active when the generator-iterator was instantiated" is harder to follow.
I think you're mixing two concepts here: the context defines a way code is supposed to be interpreted at runtime. This doesn't have anything to do with when the code is actually run. Just think what happens if you write code using a specific context (let's say rounding to two decimal places), which then get executed deferred within another context (say rounding to three decimal places) for part of the generator run and yet another context (say rounding to whole integers) for the remainder of the generator. I can't think of a good use case where such behavior would be intuitive, expected or even reasonable ;-) The context should be inherited by the generator when instantiated and not change after that, so that the context defining the generator takes precedent over any later context in which the generator is later run. Note that the above is not the same as raising an exception and catching it somewhere else (as Nathaniel brought up). The context actually changes semantics of code, whereas exceptions only flag a special state and let other code decide what to do with it (defined where the exception handling is happening, not where the raise is caused). Just for clarification: I haven't followed the thread, just saw your posting and found the argument you put forward a bit hard to follow. I may well be missing some context or evaluating the argument in a different one as the one where it was defined ;-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/