[PATCH 1 of 2 stable] WHAT: PyExc_TypeError in parsers.c is lost - use PyExc_ValueError instead

Mads Kiilerich mads at kiilerich.com
Thu Oct 23 19:37:11 CDT 2014

On 10/23/2014 03:30 AM, Pierre-Yves David wrote:
> I believe that the changelog is catxching the TypeError:
> http://selenic.com/hg/file/d583f1cfca96/mercurial/changelog.py#l172

Right, thanks.

I was sure changelog was calling the C extension directly. I assumed I 
was right. Wrong assumptions can invalidate even the best reasoning. :-(

> We should fix that code to explicitly check for the C version 
> attribute and stick on type error.

Which C version attribute? AFAIK the C extension (and Mercurial in 
general) don't have version numbers, only features.

Unfortunately, in this case the C extension got a new feature, and the 
absence of that feature can only be detected as TypeError when calling 
with a parameter ... which unfortunately is indistinguishable from other 
runtime type errors. inspect only works on Python code.

(Ok, not completely indistinguishable. We could check if TypeError .args 
== ('headrevs() takes no arguments (1 given)',) ... but that is too ugly.)

AFAICS, the only options are to check on something existing, or to add 
something we easily can check.

AFAICS, the only existing thing we can check is asciilower which was 
introduced after the filtering headrevs.

Alternatively, we could introduce a version number or rename headrevs or 
add a filteringheadrevs method or do something else we can detect.

3.2 is a new major version and there has been significant improvements 
to the C extension. It could perhaps make sense to require new 
extensions for this version.


More information about the Mercurial-devel mailing list