pygame and python 2.5

Ben Sizer kylotan at gmail.com
Fri Feb 9 17:56:20 EST 2007


On Feb 9, 9:01 pm, s... at pobox.com wrote:
>     Ben> If someone could explain the limitation in detail, I expect ways
>     Ben> could be found around it. After all, I don't know of any other
>     Ben> systems that require you to recompile all the extensions when you
>     Ben> upgrade the application.
>
> Python used to work that way.  You'd then silently get errors if the API
> changed between version A and version B and you neglected to recompile the
> extensions you compiled against version A.  Maybe the Python extension API
> is mature enough now that it can be frozen, but I sort of doubt it.

The only reason this is an issue is because the system is tightly
bound on a binary level. Decouple that and the problem goes away.
These 'silent' errors will all stem from a small number of specific
things, each of which can be addressed. eg. PyFile_AsFile returns a
FILE*, which is all well and good if both the extension's compiler and
the language's compiler agree on what you get when you dereference
that type, and probably not so good when they don't. The answer there
is not to make assumptions about the structure of complex types across
the boundary. The same may well go for the multitude of macros that
make assumptions about the structure of a PyObject.

It's not really much to do with the maturity, since functions don't
seem to be getting regularly removed from the API. It's more the
choices made about how to implement it.

--
Ben Sizer




More information about the Python-list mailing list