On Sat, Nov 21, 2009 at 11:05 AM, "Martin v. Löwis" <mar...@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@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/casevh%40gmail.com
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
