[PATCH 0 of 1 stable 3] accept long as revs

[Matt Mackall]

On Sun, 2012-06-24 at 14:36 +0200, Sune Foldager wrote:
> Well either it works everywhere it did before the new C-module, or
> not. Catching it in one place isn't gonna help me. The C-code made it
> regress from accepting longs to only doing it in some places.

I'm afraid I have to draw the line here. Further uglifying otherwise
perfectly correct C code to meet the needs of obviously misguided
third-party code is just not going to happen.

> I know we don't have a stable API, but generally we don't regress needlessly.

But it's wasn't needless! We didn't change things just to change things,
we did it to make things significantly faster. And making it faster
meant switching to an API where type coercion from long is no longer
'free' and thus went implemented as there's no known valid use case.
Obviously no one will ever have 4 billion changesets on a 32-bit
machine.

This is actually a perfect example of why there's no stable internal
API. If we let silly API abuses in third-party code constrain the API,
we have to live with crap like this forever:

	/* hgtk passes longs (??!!) and no one is likely to ever
           fix it, so we need this extra check and slow function call
           in the fast path, please don't remove it */
        if (PyInt_Check(value) || PyLong_Check(value))
                return index_get(self, PyLong_AsLong(value));

There's zero back-pressure on hgtk to ever clean this up.

On the other hand, if we break some API user accidentally and unbreaking
it has no downsides like the above maintenance baggage, yes, I'm
perfectly happy to do it.

-- 
Mathematics is the supreme nostalgia of our time.