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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com