Finally got SimpleParse updated to use Py_ssize_t
Written by
on
in
Snaking.
I finally sat down this evening to get SimpleParse updated to use the Py_ssize_t type instead of ints for tracking offsets, lengths and the like. Was lots and lots of trivial updates, rather than anything particularly difficult... exactly the kind of thing I hate spending time on.
Anyway, don't yet have a Python2.6 compilation setup for Win32, so haven't updated the installers yet. I'm going to go back to using raw distutils instead of setuptools before doing that, likely. Also going to switch to LaunchPad for the bzr repository.
What's Py_ssize_t? It's the unsigned int type which allows you to do greater-than-32-bit-sized arrays and the like on 64-bit hardware. It's been the "correct" way to do indexing in Python for a while.
[Update] Python 2.6 compilation, it turns out, is not going to be VC++ Express... turns out that requires XP or Vista and my dev Win32 machines are Win2K. Guess I'll be trying out MingW32.
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Roger on 11/10/2008 12:51 a.m. #
Py_ssize_t is *signed* - that is why there are two 's'. That means you can use negative numbers if you want (eg to index from the end if you implement that) or use a sentinel value of minus 1 to mean everything etc.
There is no Py_size_t (ie unsigned type)
Christian Heimes on 11/10/2008 4:24 a.m. #
Roger's analysis is correct. There is no need for a Py_size_t data type because size_t (unsigned size type) is a standard in C. stdlib.h is required to define size_t.
Michael Foord on 11/10/2008 5:02 a.m. #
If SimpleParse can be compiled with a simple
setup.py bdist_wininst
then I'm happy to build and run tests for you on Vista.
Mike Fletcher on 11/10/2008 9:11 p.m. #
Ah, then this is why people recommended using Py_ssize_t, as the original was int, so signed and allowing for sentinel values.
Roger on 11/10/2008 9:16 p.m. #
Also you need to use Py_ssize_t (and Py_size_t if that ever existed) because Python earlier than 2.5 used int (ie 32 bits) even in 64 bit processes. You'll generally want the sizes in your code to match that used by Python.
Mike Fletcher on 11/10/2008 10 p.m. #
Thanks for the offer, but I really need to get the tool-chain built so I can build e.g. pyvrml97's accelerators and likely a PyOpenGL accelerator at some point.