On Thu, 21 Aug 2008, Dag Sverre Seljebotn wrote: > Lisandro Dalcin wrote: >> Dag, you proposal is a strong one. Just pulled from cython-dagss. Then >> some comments below. > > Well, it is meant only as input to the discussion so that Greg's proposal > isn't taken on right away (because there's no clean backwards-compatible > way back then). I don't think we have the developer resources for it now > -- I'd need up to a week fulltime to do the whole thing properly and I > don't have that (and there are other priorities within Cython too).
Yes. I think the point that one cannot ever safely go back to the old behavior is critical and one of the main reasons I wouldn't like to make this change (except as a compiler option). > I even found a few critical bugs in my prototype since I wrote it. > > For now we could do a simple non-optimized thing (check on *every* access) > which is controlled by a compiler directive (but it would default to off > then). That should only take a few hours. > >> Could you optimize the case below? >> >> def default(MyClass var): >> if var is None: var = MyClass(4, 5) >> print var.a > > Are you sure you can optimize it? MyClass could be set to a function > returning None at run-time, so you don't know that it isn't None. (Or > __new__ could return None, if extension types support that kind of thing, > I don't know). > > (I have a proposal in the pipeline that would solve this issue but there's > enough on the mailing list for this week so it will have to wait, but > given that mystic proposal which I won't talk about, the answer is "yes", > it could be optimized, but it would likely take some work and not be in > the initial version of this thing). > >> Additionally, no checks should be done in this case: >> >> def strinct(MyClass var not None): >> print var.a > > Yes, this is trivial. > > What worries me most is this: > > for i in range(large): > print var.a > > In order to optimize this, one would need to unroll the first iteration of > the loop. So that is getting so complicated that it likely will never > happen I think. > > As a fun aside, once you get into nested expressions like this: > > if (a is not None and b is not None and c == 2) or (a is None and c == 1 ... > > then we've got an instance of SAT (i.e. can't solve in polynomial time > "unless P = NP"). But I think there's a rather natural cutoff point for > the complexity of expressions we consider. Optimizations of this nature should be considered when we have some kind of control flow analysis implemented. Variable assignment will certainly be tracked. This check could be done on the first attribute access attempt, and then known to be true until an assignment is made. One could try and optimize things even further, like simple "if a is not None: ...", but beyond that I would guess the return on investment drops off quickly. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
