[Python-Dev] Type of range object members

[Alexander Belopolsky]

On Aug 15, 2006, at 12:14 AM, Guido van Rossum wrote:

>
> Feel free to submit a patch for Python 2.6.

Please see http://sourceforge.net/tracker/index.php? 
func=detail&aid=1540617&group_id=5470&atid=305470


> Perhaps it is in POSIX?

Yes, "ssize_t - Used for a count of bytes or an error indication.",  
defined in sys/types.h .

I promised to shut up, but let me respond to Martin:

On Aug 15, 2006, at 3:25 AM, Martin v. Löwis wrote:
> Alexander Belopolsky wrote:
>> [snip] I did not notice the double 's' and thought it was an
>> unsigned type.
>
> Hmm. That you fail to read it correctly can hardly be an argument
> against it.

Google tells me I am not the only one: <http://dbforums.com/ 
showthread.php?t=1430615>.
What happened to "readability counts"?


>
> In the rationale (XRAT) they say
>
> "This is intended to be a signed analog of size_t."

That's POSIX rationale <http://www.opengroup.org/onlinepubs/009695399/ 
xrat/xsh_chap02.html>. PEP 353 says: "A new type Py_ssize_t is  
introduced, which has the same size as the compiler's size_t type,  
but is signed."

>
> They don't mandate it to have the same size, but it is the expectation
> that implementations typically will.

That's one of the reasons why POSIX' ssize_t is a wrong analogy.   
Another reason is that POSIX interprets negative values of ssize_t as  
"an error indication", not as an offset from the end. A better POSIX  
analogy would be off_t (as used in lseek).

>
> In the discussion, ptrdiff_t was never brought up as an alternative

Yes, it was, by you <http://mail.python.org/pipermail/python-dev/2006- 
January/059562.html> :-).

I was not suggesting Py_ptrdiff_t.  My suggestion was "Py_index_t",  
but I am six month late :-(.