<br><br><div><span class="gmail_quote">On 5/29/06, <b class="gmail_sendername">"Martin v. Löwis"</b> <<a href="mailto:martin@v.loewis.de" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
martin@v.loewis.de</a>> wrote:</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I agree using Py_ssize_t would be a "smaller" change, and one that<br>likely has less performance impact. It would still be a large change,<br>and should be only done if we know for sure we don't want it to be<br>
a 64-bit type always the next day.</blockquote><br></div>Well, implementing PyInt in terms of a new symbolic type, even if it defaults to 64-bit, should make choosing it to be a 32-bit type a lot easier, shouldn't it?<br>
Not that I think defaulting PyInt to use 'long long' is a good thing, considering we still only compile 'long long' support optionally. Better to stick with a common native type until all machines have 64-bit registers.
Better for performance, too.<br><br>But switching PyInts to use (a symbolic type of the same size as) Py_ssize_t means that, when the time comes that 32-bit architectures are rare, Win64 isn't left as the only platform (barring other LLP64 systems) that has slow 33-to-64-bit Python numbers (because they'd be PyLongs there, even though the platform has 64-bit registers.) Given the timeframe and the impact, though, perhaps we should just do it -- now -- in the p3yk branch and forget about
2.x; gives people all the more reason to switch, two years from now.<br clear="all"><br>-- <br>Thomas Wouters <<a href="mailto:thomas@python.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
thomas@python.org</a>><br><br>Hi! I'm a .signature virus! copy me into your .signature file to help me spread!