Python-list digest, Vol 1 #12210 - 15 msgs

[Skip Montanaro]

    Skip> When compiling, you can't assume anything about the input
    Skip> parameters or return value of range().  You need a new construct
    Skip> which says, "this is how to enumerate the integers between x and
    Skip> y."

    Matthias> But surely in the context of Pyrex you could make assignment
    Matthias> to builtins illegal? (after all Pyrex isn't Python, it just
    Matthias> looks like it <wink>)

    Terry> This makes sense to me too. Is there actually anything to be
    Terry> gained by overloading range() like this? 

Actually, in all the years I've programmed with Python, I've never
overridden range(), certainly not with the trick I demonstrated.  In my
younger days I have inadvertently overridden compile() and list() however,
and not by inserting them into __builtins__, just by naively creating new
objects with those names.

I wasn't suggesting that overriding range() was a good idea, just suggesting
why Greg might not have jumped at the chance to assume range() always meant
the range() function we know and love from builtins.

    Terry> Of course, if it's really nasty to implement, I can see the new
    Terry> syntax as a reasonable compromise...

It's not that it would be nasty to implement, just that semantically range()
would be more like a keyword than a function.  You'd be placing restrictions
on it which you wouldn't place on other functions.

Skip