Re: 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@...>

Re: 100% CPU FAQ

http://pyglet.googlecode.com/issues/attachment?aid=-8684410250382500806&name=shadowtestbattery.zip

and

http://sebastian-tillmann.de/stuff/shadow-1.0.0.tgz

2008/8/1 Noah Kantrowitz <noah@...>:

>
> Where is this code?
>
> --Noah
>
>

Re: 100% CPU FAQ

RE: 100% CPU FAQ

> -----Original Message-----
> From: owner-pygame-users@... [mailto:owner-pygame-users@...]
> On Behalf Of Python Nutter
> Sent: Thursday, July 31, 2008 4:09 PM
> To: pygame-users@...
> Subject: Re: [pygame] 100% CPU FAQ
> 
> http://pyglet.googlecode.com/issues/attachment?aid=-
> 8684410250382500806&name=shadowtestbattery.zip

I see no Pygame version in this.

> and
> 
> http://sebastian-tillmann.de/stuff/shadow-1.0.0.tgz

This is a 404 for me.

--Noah

Re: Python 3.0 to be backwards incompatible ?

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@...> 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@...>
>
>

Re: 100% CPU FAQ

Re: Python 3.0 to be backwards incompatible ?

Re: 100% CPU FAQ

Noah Kantrowitz wrote:
> If you want to control 
> your framerate (and therefore CPU usage) use pygame.time.Clock.

Alternatively, use pygame.time.set_timer to arrange for a
USEREVENT to be sent at regular intervals.

In your event loop, use pygame.event.wait(), which does
block (but only returns one event at a time).

If you want to get multiple events in one go, use
pygame.event.wait() to get the first one, then call
pygame.event.get() to get any others that have been
put in the queue since the last time round the event
loop.

--

-- 
Greg

Re: Python 3.0 to be backwards incompatible ?

No-one was ever forced to import operator, the old way to force float  
division was just to ensure one of the operands was a float, e.g.,

c = float(a) / b

float is a built-in, so no import needed. Regardless having an  
explicit integer division operator is much better.

-Casey

On Jul 31, 2008, at 5:40 PM, Paulo Silva wrote:

> 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@...>  
> 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@...>
>>
>>

Re: Python 3.0 to be backwards incompatible ?