Armin Rigo wrote:
>  I guess you mean LONG_MAX instead of MAX_INT, in the event that ssize_t
>  is larger than a long.

Right, changed.

>  Also, distinguishing between PyInt_AsSsize_t()
>  and PyLong_AsSsize_t() doesn't seem to be useful (a quick look in your
>  branch makes me guess that they both accept an int or a long object
>  anyway).

In changing this, I found there is a difference: callers typically check
for int, then do PyInt_AS_LONG, and use the result right away, then
they check for long, use PyLong_AsSsize_t, check for a -1 result, check
if an exception occurred, and only then use the result.

With PyLong_AsSsize_t gone, this can be unified (done in r41851);
the code becomes clearer, but there will be more type checks in the
usual code path.

>  Hum.  It would be much cleaner to introduce a new format character to
>  replace '#' and deprecate '#'...

That would certainly be clearer. What character would you suggest?

I see two drawbacks with that approach:
1. writing backwards-compatible modules will become harder.
   Users have to put ifdefs around the ParseTuple calls (or atleast
   around the format strings)
2. I see this as a transitional change; in P3k, indexing should be
   done exclusively through Py_ssize_t. Then '#' can be removed,
   and we are stuck with that other character.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev@[...].org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.c
om