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
<[EMAIL PROTECTED]>
