[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Christian Heimes added the comment: Go ahead! The intobject header file used to make porting to Python 3 easier. Nowadays it's no longer required. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Roundup Robot added the comment: New changeset 6df456f8fc6d by Stefan Krah in branch '3.3': Issue #7353: Remove references to Include/intobject.h in the C-porting howto. http://hg.python.org/cpython/rev/6df456f8fc6d -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Changes by Stefan Krah stefan-use...@bytereef.org: -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed versions: +Python 2.7, Python 3.3, Python 3.4 -Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Ramchandra Apte added the comment: Bump... is this still valid? -- nosy: +ramchandra.apte ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Stefan Krah added the comment: I tend to agree with the argument that the removal of intobject.h was a good thing, since it avoids subtle errors. Probably no one wants to reinstate intobject.h at this point, so unless there are objections, I'll update the docs in a couple of days. -- keywords: +patch nosy: +skrah Added file: http://bugs.python.org/file28758/issue7353.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Changes by Éric Araujo mer...@netwok.org: -- assignee: - d...@python nosy: +d...@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Changes by Skip Montanaro s...@pobox.com: -- nosy: -skip.montanaro ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Iustin Pop iu...@k1024.org added the comment: Hi, Might I suggest that, whatever the outcome of the re-adding intobject.h discussion, the documentation is updated? I think I'm not the only module author which spent time trying to understand why the 3.1 documentation refers to non-existent header before finally finding this bug :) thanks a lot, iustin -- nosy: +iustin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Eric Smith e...@trueblade.com added the comment:
MvL made this comment in
http://www.mail-archive.com/python-...@python.org/msg43844.html
I'm copying it here so it doesn't get lost and because I think he makes
a good point that many people would miss (at least I didn't think of it).
---
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
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7353
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Marc-Andre Lemburg m...@egenix.com added the comment:
Eric pointed me to this ticket after having raised the question on
python-dev: http://www.mail-archive.com/python-...@python.org/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-...@python.org/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 rep...@bugs.python.org
http://bugs.python.org/issue7353
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Guido van Rossum gu...@python.org added the comment: I don't think it would hurt to put it back, would it? I think the remove this in 3.1 note was made when we expected 3.1 to be happening 1.5 years after 3.0 rather than a few months. -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Mark Dickinson dicki...@gmail.com added the comment: [Benjamin] I wish intobject.h hadn't been removed so soon. Yes; I'm sorry about that. I'm not really sure how a file of #defines could suffer bitrot. Good point. Me neither. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
R. David Murray rdmur...@bitdance.com added the comment: You didn't. Doc bugs are automatically assigned to Georg by the tracker. -- nosy: +r.david.murray priority: - normal stage: - needs patch title: Why was Include/intobject.h removed in 3.1? - cporting docs recommend using Include/intobject.h, which was removed in 3.1? type: - behavior versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: -r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7353] cporting docs recommend using Include/intobject.h, which was removed in 3.1?
Benjamin Peterson benja...@python.org added the comment: Hmm, I wish intobject.h hadn't been removed so soon. I'm not really sure how a file of #defines could suffer bitrot. This point is probably moot, though because there's little point in having its presence skip a version. I suppose sticking it in Tools or even Doc/includes is the second best option. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
