division operator were the first thing came on mind when reading about this - i'ts really annoying having to do 'c=operator.truediv(a,b)' instead of merelly' 'c=a/b', and having to set 'import operator' at the start of the code...
---------------------------- On Fri, Aug 1, 2008 at 12:05 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > 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]> > >
