report at bugs
Nov 23, 2009, 4:52 AM
Post #7 of 7
(231 views)
Permalink
|
|
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
[In reply to]
|
|
Marc-Andre Lemburg <mal [at] egenix> added the comment:
Eric pointed me to this ticket after having raised the question on
python-dev: http://www.mail-archive.com/python-dev [at] python/msg43841.html
I think the discussion should be continued there instead of on this ticket.
Just for completeness, I'm copying my reply to Martin's reply here
(http://www.mail-archive.com/python-dev [at] python/msg43849.html):
"""
> 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.
Sure, but that assumes that the original code already had support
for Python longs, which a lot of code doesn't.
In an ideal world, developers would add that code to their
extensions right away. In the real world, where developers only
have limited resources available, you'll get more 3.x ports
by making such ports as painless as possible while at the
same time not forcing them to alienate their 2.x user base.
The long support could then be added in later releases
of the extensions, giving the developers more time adapt.
> 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.
That's not quite true: PyInt_AsLong(obj) will try the
nb_int slot on non-integer objects which can return errors
(it returns -1 and sets the error message).
> So eliminating intobject.h likely helps avoiding subtle errors.
In the long run, yes. In the short run, other criteria are
more important, IMHO.
"""
IMO, it would be worthwhile collecting all Python 2.x compatibility C
APIs in two new files:
* py2compat.h
* py2compat.c
These could then be used in extensions and make the use of such
compatibility APIs explicit in the extension.
----------
nosy: +lemburg
_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue7353>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com
|
