Stefan Behnel wrote: > Hi, > > now that we can guarantee Python semantics for the optimised for-in-range > loop, should we enable the optimisation also when the loop variable is not > explicitly typed, but when the range is constant and clearly within int > bounds?
If this is done, I'd go even further and always do it. At least under Python 2: >>> for i in xrange(10**90): pass ... Traceback (most recent call last): File "<stdin>", line 1, in <module> OverflowError: long int too large to convert to int But I really thing that range() is such a common use, and super-ints so seldom, that I'd propose this as the one place it would make sense to break Python compatability also if Py3 fixes this (but keep a cython.bigrange which isn't optimized -- Sage has a corresponding srange I think). > We might consider waiting with these things until we have flow analysis in > place to make sure the loop variable isn't assigned non-int values inside > the loop, but I doubt that this will be a common case. My instinct is to wait until we can start implementing some kind of simplistic type inference transform, with this as the first simple case to deal with, rather than specific code for the for-in-range. That would depend on flow analysis though. So my instinct is to wait, but practicality might push this special case ahead as you say. I'm not sure. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
