[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Python 3.0 to be backwards incompatible ?



Paulo Silva wrote:
http://it.slashdot.org/article.pl?sid=08/02/01/1624247

well, this sounds to me as a huge headache... but i'd like to know
oppinions about (what will be improved, what will be changed),
specially all Pygame coders, and how far it may affect Pygame games
supposed to be 'considered' done...
Pygame has been built for Python 2.6 on Windows as a first step in the migration to Python 3.0. Getting SDL to link against the Visual Studio 2008 C runtime was a headache, but it is done. Also all the unit tests being added will help in the migration to 3.0. They exercise the various execution paths with Pygame for Python 2.6's compatibility warnings. My concern is the C api. I assume it has settled down for Python 3.0 and will not differ much from 2.x. But there will likely be enough subtle differences to create confusion.

One thing a Pygame for 3.0 can use is the new buffer protocol. The new protocol explicitly signals the release of shared memory. Traditionally only the reference to the owning object is decremented. This makes surface locking problematic. A surface is locked when its buffer is accessed. Currently an intermediary buffer object unlocks the surface when it is garbage collected. With 3.0 the unlocking can be direct. Though the new protocol is present in 2.6, the 2.x version of Pygame needs to remain backwards compatible.

--
Lenard Lindstrom
<len-l@xxxxxxxxx>