ANN: Pyrex 0.4.3

[Skip Montanaro]

    Ram> Why not just check if the range() object is the one that would have
    Ram> been returned by the builtin function? If the object is the normal
    Ram> one then you know you can generate C code - and if its not the
    Ram> normal one then you can stick to the curreny python
    Ram> behaviour... you get the speed you want without introducing a new
    Ram> syntax.

Nice idea, however because module dicts are writable, range() might be
overridden at runtime, just like in my weird example.  Greg can't assume the
range() available to Pyrex is the same range() that will be available when
the program is run.

Trust me folks...  I know it seems very weird that you can't make these
simplifying assumptions, but you can't if you want to maintain Python
semantic compatibility.  Greg's a very smart guy.  I'm sure he weighed the
pros and cons of the various options available to him before he settled on
adding a new syntactic construct to Pyrex.  While Pyrex != Python, most
Pyrex programmers will already be Python programmers.  Specifying integer
looping semantics with new syntactic sugar will lead to fewer surprises.

Skip