Customize the effect of enumerate()?

[Dustan]

Fredrik Lundh wrote:
> "Dustan" wrote:
>
> > Except that my program is supposed to be treated as a module with tools
> > to do certain things. I certainly can't control whether a 3rd party
> > programmer uses "import myModule" or "from myModule import *".
>
> anything can happen if people use "from import *" in the wrong way, so that's
> not much of an argument, really.
>
> </F>

My argument was that if they use "import myModule", overriding
enumerate() wouldn't work. So "from myModule import *" would work
nicely, but not the former. Given that, I'm not getting your rebuttal,
or whatever it is.


Steven D'Aprano wrote:
> On Sun, 22 Oct 2006 15:56:16 -0700, Simon Forman wrote:
> > That final else clause is a little funny...    What kind of indices are
> > you expecting that will be neither less than zero, greater than zero,
> > or equal to zero?
>
> Possible a NaN value? Maybe a class instance with strange comparison
> methods?
>
> Personally, I don't like the error message. "Invalid index" doesn't really
> tell the caller what went wrong and why it is an invalid index. If I were
> programming that defensively, I'd write:
>
> if item > 0:
>     return self.sequence[item-1]
> elif item < 0:
>     return self.sequence[item]
> elif item == 0:
>     raise IndexError, "Index 0 is not valid."
> else:
>     print repr(item)
>     raise ThisCanNeverHappenError("Congratulations! You've discovered "
>     "a bug that can't possibly occur. Contact the program author for "
>     "your reward.")
>
> I know some programmers hate "Can't happen" tests and error messages, but
> if you are going to test for events that can't possibly happen, at least
> deal with the impossible explicitly!

I certainly can't argue with that logic; I might even go so far as to
agree with you and start raising impossible errors with this kind of
explicitness.

What reward should I offer? ;-)