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).
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.
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
