[Python-Dev] Optimization of the Year

[Guido van Rossum]

> Guido van Rossum wrote:
> > I'm all for this.  I imagine there are many subtleties though -- I
> > know I consciously chose 'int' for this purpose in Python 0, and the
> > assumption that it fits in an int is everywhere.  I would trust a
> > decent compiler to find most cases, but not all.

[MvL]
> The MS Win64 compiler (Itanium) is pretty good at finding size_t/int
> conversions, as size_t is wider even than long on the system. I have
> patches sitting on my disk to change all function signatures, but
> not the structure layouts. They are (unfortunately) still incomplete,
> and it is doubtful whether I can complete them before PyCon.

Maybe it can be a sprint topic?

> > Also, occasionally (size_t)(-1) may be used to indicate an error
> > (e.g. PySequence_Size()).
> 
> This is the tricky part that I want to defer in the first round
> of patches: I believe ob_size should be a signed type, so it should
> be ssize_t where available. The tricky part is finding an appropriate
> type on systems where ssize_t is not available.

Why not simply use Py_intptr_t then?

> (size_t)(-1) is not a problem per se; this is well-defined on all
> ISO C compilers. However, some code may expect that the error marker
> is smaller than any other value, which would not be the case for
> (size_t)(-1).

Right, that's what I meant.

--Guido van Rossum (home page: http://www.python.org/~guido/)