It could set *overflow to -1 on negative value and to 1 on overflow.
And PyLong_AsUnsignedLongLongAndOverflow.

Sounds reasonable to me.  Were there particular uses you needed this for?  And do you want to work on a patch?

> Sounds reasonable to me.  Were there particular uses you needed this for?  And do you want to work on a patch?

I don't understand why PyArg_Parse*() functions have formats for integers checking overflow for signed integers, but not for unsigned integers. For the zlib module, I had to develop my own format format (to get an unsigned int with overflow check) :-(

Please apply in 3.4.1. I need this ASAP.

> Please apply in 3.4.1. I need this ASAP.

New functions are new features, and new features are no more added after a release (ex: 3.4.0). If something is changed, it will done in Python 3.5.

You can add PyLong_AsUnsigned*AndOverflow() functions to your project so you will support older versions too, like Python 3.3.

Will you release 3.5 in the next few weeks?

No

I will not add PyLong_AsUnsigned*AndOverflow in my code because I don't want my code to depend on the exact implementation of PyLong.

Are you seriously calling a 50-line function "feature"?

Anyway... I propose splitting the patch in two parts:
   - "cleanup": the changes to Objects/longobject.c
   - "feature": the changes to Include/longobject.h

"cleanup" can be applied to 3.4.1 because it adds no new features and helps maintainability. Backwards compatibility will not be broken.
"feature" can then be added in 3.5. Backwards compatibility should not be broken.

Thanks for the patch!  I left a couple of comments on Rietveld.  The patch will also need docs and tests before it's ready to go in.

There's a behaviour change in the patch which needs looking into: before the patch, PyLong_AsUnsignedLong will not call the target object's __int__ method (so it should raise a TypeError for a float or Decimal instance, for example).  It looks to me as though the patch changes that;  was that change intentional?

I did not intend to make it so that PyLong_AsUnsignedLong* to call __int__ but it looks like a good idea because PyLong_AsLong* does that and the patch is exactly about that - removing differences between converting to signed and unsigned.

Should I upload the patch with docs and with the warning fixed? Will it be applied in 3.4.1? It will be a lot easier to check the value of an int than to create a new PyLong = 2^64 and compare the number with that.

P.S.: is there a very fast way to check if a PyLong fits in unsigned long long with the limited API?
P.P.S.: Just a random idea: would it be a to rewrite PyLong to use GMP instead as a PyVarObject of mp_limb_t's?

> it looks like a good idea

It's not a good idea, though: you risk breaking existing third-party extension modules in surprising ways, which isn't a friendly thing to do.  In any case, if anything the PyLong methods should be moving *away* from use of the nb_int slot.  This has been discussed multiple times previously; one reason that we haven't made that change yet is the problem of breaking backwards compatibility.

> Should I upload the patch with docs and with the warning fixed?

Sure, that would be great if you have the time.  Tests would be useful too, but one of us can fill those in (eventually).  It all depends how much of a hurry you're in. :-)

> Will it be applied in 3.4.1?

No: as already explained by others, it's a enhancement, not a bugfix, so it can't be applied until 3.5.

> P.S.: is there a very fast way to check if a PyLong fits in unsigned long long with the limited API?

Depends on your definition of 'very fast'.  There should be no need to compare with a constant: just try the conversion with PyLong_AsUnsignedLong and see if you get an OverflowError back.  My guess is that that's not going to be much slower than a custom PyLong_AsUnsignedLongAndOverflow, but the only way you'll find out is by timing your particular use-case.

> P.P.S.: Just a random idea: would it be a to rewrite PyLong to use GMP instead as a PyVarObject of mp_limb_t's?

I'll let Victor answer that one. :-)  In the mean time, see issue 1814.

> > P.P.S.: Just a random idea: would it be a to rewrite PyLong to use GMP instead as a PyVarObject of mp_limb_t's?
> I'll let Victor answer that one. :-)  In the mean time, see issue 1814.

During the development of Python 3.0, I wrote a large patch to reuse directly GMP for Python int. My conclusion is here:
http://bugs.python.org/issue1814#msg77018
(hint: "it's not a good idea")

IMO the first problem is the memory allocation. GMP type doesn't fit well with Python type. GMP type for "int" has a fixed size, and then GMP allocates a second structure for digits. It's inefficient for small integers, and almost all Python int are small (smaller than 32 or 64 bits).

Here's an updated patch, for PyLong_AsUnsignedLongAndOverflow only, including docs and tests.

Let's close this one. The patch is stale, and I think we should be somewhat cautious about expanding the C-API without clear use-cases - I don't think it's worth adding the new function just for symmetry / consistency. I'm happy to re-open if those use-cases emerge.