mal at egenix
Nov 23, 2009, 3:05 AM
Post #6 of 11
(1475 views)
Permalink
|
"Martin v. Löwis" 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.
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.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Nov 23 2009)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
|
