[Python-Dev] Type of range object members
Alexander Belopolsky
alexander.belopolsky at gmail.com
Tue Aug 15 16:32:45 CEST 2006
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 :-(.
More information about the Python-Dev
mailing list