[Python-checkins] r60707 - in python/trunk: Include/intobject.h Include/longobject.h Objects/abstract.c Objects/intobject.c Objects/longobject.c

[Neal Norwitz]

Sorry for the delay.  I saw your new checkin, I think that version is
fine.  It would also be ok to do something like:

if (PyInt_Check(o)) {
  ...
} else {
  assert(PyLong_Check(o));
  ...
}

since PyNumber_Index() must return either an int or long.

n

On Wed, Feb 13, 2008 at 12:28 AM, Eric Smith
<eric+python-dev at trueblade.com> wrote:
>
> Eric Smith wrote:
>  > Neal Norwitz wrote:
>  >>> +PyObject *
>  >>> +PyNumber_ToBase(PyObject *n, int base)
>  >>> +{
>  >>> +       PyObject *res = NULL;
>  >>> +       PyObject *index = PyNumber_Index(n);
>  >>> +
>  >>> +       if (!index)
>  >>> +               return NULL;
>  >>> +       if (PyLong_Check(index))
>  >>> +               res = _PyLong_Format(index, base, 0, 1);
>  >>> +       else if (PyInt_Check(index))
>  >>> +               res = _PyInt_Format((PyIntObject*)index, base, 1);
>  >>> +       else
>  >>> +               assert("PyNumber_ToBase: not long or int");
>  >> The assert() should be changed to something like:
>  >>
>  >>     PyErr_SetString(PyExc_ValueError, "arg not int or long");
>  >>
>  >> Otherwise this will raise a SystemError in non-debug builds.
>  >>
>  >>> +       Py_DECREF(index);
>  >>> +       return res;
>  >>> +}
>  >
>  > I was going to change that, but this is copied from py3k's
>  > PyNumber_ToBase, which is:
>  >
>  > PyObject *
>  > PyNumber_ToBase(PyObject *n, int base)
>  > {
>  >          PyObject *res;
>  >          PyObject *index = PyNumber_Index(n);
>  >
>  >          if (!index)
>  >                  return NULL;
>  >          assert(PyLong_Check(index));
>  >          res = _PyLong_Format(index, base);
>  >          Py_DECREF(index);
>  >          return res;
>  > }
>  >
>  >
>  > So I figured the assert was okay.  Should it be changed in both places?
>  >   I was thinking that it should be PyErr_BadInternalCall().
>
>  To which I meant to add:  But of course you know better than me.
>
>  Also, it turns out I don't need this function for my PEP 3101 work.
>  Maybe PEP 3127 will need it, but I'm speculating.  I do need the support
>  routines it calls, however (_PyLong_Format and _PyInt_Format).
>