[Python-Dev] Removal of intobject.h in 3.1

Case Vanhorsen casevh at gmail.com
Sat Nov 21 21:00:41 CET 2009


On Sat, Nov 21, 2009 at 11:05 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> IMHO, that's not really a good way to encourage people to try to provide
>> a smooth upgrade to the 3.x branch. Much to the contrary. 3.x should make
>> it easier for developers by providing more standard helpers like
>> the removed intobject.h header file.
>
> I think it's better than it sounds. The macros (unfortunately) allowed
> to make non-obvious mistakes. Now that they are gone, people need to
> really think of what precisely they want to do.
>
> For example, consider
>
> if (PyInt_Check(o)){
>  long val = PyInt_AsLong(o);
>  // process
> } else if (PyLong_Check(o)) {
>  long long val = PyLong_AsLongLong(o);
>  // check for overflow
>  // process
> }
>
> With intobject.h, this code would continue to compile, but work
> incorrectly, as the second case will never be executed. It would
> be better to port this as
>
> #if Py2.x
> if (PyInt_Check(o)){
>  long val = PyInt_AsLong(o);
>  // process
> } else
> #endif
> if (PyLong_Check(o)) {
>
> i.e. eliminating the int case altogether. For another example,
>
> long foo = PyInt_AsLong(Foo);
>
> has a hidden error in 3.x, with intobject: PyLong_AsLong might
> overflow, which the 2.x case doesn't.
>
> So eliminating intobject.h likely helps avoiding subtle errors.

FWIW, I ported gmpy to Python 3.x without using intobject.h. I'm now
using the #if Py2.x  ... #endif approach (almost) everywhere.  The
same source compiles successfully with Python 2.4 to 3.2.

Case
>
> Regards,
> Martin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/casevh%40gmail.com
>


More information about the Python-Dev mailing list