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

[Sune Foldager]

On 2012-06-26 03:54, Matt Mackall wrote:
>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.

Fine, it's not a big enough deal for me to continue this.

Consistency with how int/long is handled throughout Python. Doesn't seem
misguided to me.

>> 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.

Yeah, the new version is much faster, but hardly due to handling only
integers for their input. Unless the long/int parse operation is substantially
slower than the pure unchecked int, I doubt it can even be observed.

>Obviously no one will ever have 4 billion changesets on a 32-bit
>machine.

Well, I never argued they would.

>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));

Yeah, maybe you should stop being so negative when describing other people
and their code. Words like "misguided" and "silly API abuse", just because you don't personally
agree with it, are not necessary.

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

Well, I'll clean it up on our branch of hgtk that works against hg tip, of course,
since we use it at Edlund.

>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.

It's no big deal to me either way, but I disagree with the reasoning and the
name calling.

-Sune