On 8/14/06, Alexander Belopolsky <[EMAIL PROTECTED]> wrote: > > On Aug 14, 2006, at 10:56 PM, Guido van Rossum wrote: > > > Because the only way to create one (in 2.5 or before) is by passing it > > a Python int. > > Is that true? > > Python 2.4.2 (#2, Jan 13 2006, 12:00:38) > >>> xrange(long(2)) > xrange(2)
But a long with a value larger than sys.maxint is never accepted right? > > But since the start and end come from a Python int, what advantage > > would it have to use Py_ssize_t instead? We know sizeof(long) <= > > sizeof(Py_ssize_t). > > They don't have to come from a python int, they can come from a > long. I guess range_new would have to be changed to the 'n' > conversion code instead of 'l' to do the proper conversion. > Similarly, rangeiter_next will need to use PyInt_FromSsize_t . Feel free to submit a patch for Python 2.6. I expect the 2.5 release managers to reject this on the basis of being a new feature. > > Blame the C standards committee -- they introduced ssize_t in C99. > > I've checked in the Wiley's 2003 edition of "The C Standard" and it > does not have ssize_t . I could not find anything suggesting that it > is in the C standard on google either. Are you sure it is in C99? To be honest I have no idea how/why Martin or Tim picked this name. Perhaps it is in POSIX? I doubt they made it up; ssize_t is used all over the standard headers in the 4-year-old Linux distro (Red Hat 7.3) running on my ancient home desktop. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
