Python-list digest, Vol 1 #12210 - 15 msgs
skip at pobox.com
Wed Aug 28 00:51:58 CEST 2002
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
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.
More information about the Python-list