RetroSearch Browse

Sat Nov 21 20:05:57 CET 2009 · https://mail.python.org/pipermail/python-dev/2009-November/094339.html

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

Regards,
Martin

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2009-November/094339.html below:

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