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

["Paulo Silva" <nitrofurano@xxxxxxxxx>]

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 <len-l@xxxxxxxxx> 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
> <len-l@xxxxxxxxx>
>
>