Something weird about re.finditer()

[Aaron Brady]

On Apr 17, 9:37 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> On Sat, 18 Apr 2009 12:37:09 +1200, Lawrence D'Oliveiro wrote:
> > In message <pan.2009.04.15.09.14... at REMOVE.THIS.cybersource.com.au>,
> > Steven D'Aprano wrote:
>
> >> BTW, testing for None with == is not recommended, because one day
> >> somebody might pass your function some strange object that compares
> >> equal to None.
>
> > Presumably if it compares equal to None, that is by design, precisely so
> > it would work in this way.
>
> In context, no. We're not talking about somebody creating an object which
> is equivalent to None when treated as a value, but using None as a
> sentinel. Sentinels are markers, and it is important that nothing else
> can be mistaken for that marker or breakage will occur.
>
> Of course, if the caller knows how the sentinel is used, then he might
> choose to duplicate that usage but pass some other object. But that would
> be stupid and should be discouraged. I mean, what would be the point? I
> can think of use-cases for creating something that returns equal to None
> -- the Null object pattern comes to mind. But what would be the point of
> creating an object that was not None but would fool a function into
> treating it as the same sentinel as None?

In that case, they could use separate sentinels, that are instances of
a class or classes that have defined behavior for comparing to each
other.

It might get as bad as setting a flag on the class or sentinel, though
you'd have to be careful about concurrency and especially nested
calls.

You'd have to rely on the user function to use equality instead of
identity testing, since 'sentinel is None' won't return true no matter
what you do to it.