headers
Peter Shinners | 1 Sep 2007 01:03
Favicon
Gravatar

Re: What about python 3?

Lamonte Harris wrote:
> What do we do for python 3 :S.  When will there be information on pygame 
> and the new Python 3?

Python modules that are extensions written in C are going to have a hard 
transition to 3.0. The C API in Python 3 is different enough that porting 
will be a full rewrite.

My guess is that there won't be an official Pygame for Python 3 until 
after it is released (1 year from now). At that point the development for 
Python 2.x will probably stop.

This is just my guess though. Anything can happen with a maintainer. :-)
Permalink | Reply | 1 comment |
headers
Peter Shinners | 1 Sep 2007 01:06
Favicon
Gravatar

Re: Will there be a doc rewrite anytime soon?

Marcus von Appen wrote:
> Rene had some ideas (and plans, I think) to link the online docs
> together with the code examples, so users can directly see the usage of
> a method or another. Futher plans on the roadmap
> (http://www.pygame.org/wiki/todo) are to have an overall improvement of the
> comments and documentation.

Pygame comes with a handful of good examples. These are not usually found 
in the binary Windows package.

These small examples are far from showing the complete library.
Permalink | Reply | 4 comments |
headers
Lenard Lindstrom | 1 Sep 2007 01:15

Re: pygame.surfarray changes (PixelArray and co.)

Marcus von Appen wrote:
> On, Fri Aug 31, 2007, Marcus von Appen wrote:
>
>   
>> On, Fri Aug 31, 2007, Lenard Lindstrom wrote:
>>
>>     
>>> Just to be sure, there will be no need for Numeric include files and 
>>> libraries to compile pygame.
>>>       
>> [...]
>>
>> No. Although we need a workaround to make Numeric support buffer
>> references correctly (which needs the Numeric header), we agreed about
>> shipping it with pygame, so users do not need to install Numeric
>> explicitly.
>>     
>
> Err, I meant shipping the appropriate header, not the whole Numeric
> package, of course. We just need to guarantee that pygame builds
> properly.
>
>   

Good. Then I can remove the Numeric entry in Setup.in and the Python 
config scripts.

--

-- 
Lenard Lindstrom
<len-l@...>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Jones | 1 Sep 2007 02:22
Picon

Re: What about python 3?

On Sat, 1 Sep 2007, Peter Shinners wrote:
> Lamonte Harris wrote:
> > What do we do for python 3 :S.  When will there be information on pygame
> > and the new Python 3?
>
> Python modules that are extensions written in C are going to have a hard
> transition to 3.0. The C API in Python 3 is different enough that porting
> will be a full rewrite.

Yay for pyglet :)

    Richard
Permalink | Reply | 0 comments |
headers
Greg Ewing | 1 Sep 2007 02:54
Picon
Picon
Favicon

Re: transform.chop and image cropping

Brian Fisher wrote:
>   With regards to getting the min rect - basically various art
> production tools tend to produce output where the meaningful content
> (places where non-zero color and/or alpha values) are present is a
> subset of the entire image.

This sounds to me like something that ought to be done
once when you're creating the artwork, using some suitable
tool, before the image even gets into your game. I can't
see a reason for doing it at run time.

If it's an image generated dynamically during the game,
however, that might be different, although I can't remember
ever needing something like this.

--
Greg
Permalink | Reply | 8 comments |
headers
Brian Fisher | 1 Sep 2007 03:25
Favicon

Re: transform.chop and image cropping

On 8/31/07, Greg Ewing <greg.ewing@...> wrote:
> Brian Fisher wrote:
> >   With regards to getting the min rect - basically various art
> > production tools tend to produce output where the meaningful content
> > (places where non-zero color and/or alpha values) are present is a
> > subset of the entire image.
>
> This sounds to me like something that ought to be done
> once when you're creating the artwork, using some suitable
> tool, before the image even gets into your game. I can't
> see a reason for doing it at run time.
>
python/pygame is my suitable tool. The game itself has post-processing
stuff built in the engine. Besides, why should I make my artist run
some external tool chain? it's a waste of time when the game can
handle it. Finally, user created art can be imported run time (and
processed into a tight format for sharing, but still)
Permalink | Reply | 0 comments |
headers
René Dudfield | 1 Sep 2007 06:23
Picon
Gravatar

Re: Will there be a doc rewrite anytime soon?

Hi,

The plan is to get together a bunch of well written games and keep the
source for them on the pygame website to search and link to.

Then to do a search for each function, method, module etc within those
files - and show a list of links to each example where the function is
used.  When we link we will pass the search term, so it knows which
function to highlight.

This is what the pyopengl does to great effect with its manual.
Pyopengl keeps a very large section of examples and demos in its
subversion repository.

Another option is to use google code search.  Since I think this would
have more code indexed, and better search tools.

So the links to examples will be put in much like the doc comments are
done now.  You will need to press a button to make them visible, so
the manual is not cluttered with examples - but the examples are
visible if you click a button.

We could also do a search within the pygame cookbook, which is slowly
gaining more examples.

In some ways this won't be as good as purposely written examples for
every single feature/function.  However it will be better in a way,
since there will be more examples to look at and learn from.

On 9/1/07, Peter Shinners <pete@...> wrote:
(Continue reading)

Permalink | Reply | 3 comments |
headers
Richard Jones | 1 Sep 2007 08:13
Picon

Re: Will there be a doc rewrite anytime soon?

On Sat, 1 Sep 2007, René Dudfield wrote:
> [snip good ideas]
> We could also do a search within the pygame cookbook, which is slowly
> gaining more examples.

Or perhaps the code submitted to pyweek could be made browsable...

    Richard
Permalink | Reply | 2 comments |
headers
René Dudfield | 1 Sep 2007 08:38
Picon
Gravatar

Re: Will there be a doc rewrite anytime soon?

yeah, that could be cool too.

Here's an example of using googles code search for the
pygame.image.load function.

http://www.google.com/codesearch?q=pygame.image.load

That's pretty cool... and easy to put a link in the docs to it from
each function.

On 9/1/07, Richard Jones <richardjones@...> wrote:
> On Sat, 1 Sep 2007, René Dudfield wrote:
> > [snip good ideas]
> > We could also do a search within the pygame cookbook, which is slowly
> > gaining more examples.
>
> Or perhaps the code submitted to pyweek could be made browsable...
>
>
>     Richard
>
Permalink | Reply | 1 comment |
headers
René Dudfield | 1 Sep 2007 11:11
Picon
Gravatar

Re: What about python 3?

Hello,

What we need to do for pygame now is get *heaps* better test coverage.

This point was rammed home in a talk given by Guido about py3k.  I've
been thinking about this over the last couple of months, and test
coverage is the main thing that we should be doing now in preparation
for python 3.  There's no point targeting python 3 yet as it's still
very liquid.  By that I mean the buffer, array, string, io modules
have all been changed heaps - and are still changing.

The C API in python 3 is supposedly not going to change that much.

Guido said that in his talk at europython at least.  The idea being
that changing both python, and the C API at the same time would be a
little disastrous.  However there are already changes to the C API, so
I think that there will actually be lots of changes.

The suggested route for packages upgrading is listed on his blog posts
about py3k, and the python 3000 pep.  It's worth reading those since
there has been some thought put into it.

However there is no transition plan for people without unit tests, and
no transition plan for C API modules.  They called people silly/stupid
who don't have unit tests.  Unfortunately for them there are many
people who don't have unit tests for all their code.  They require
people to have unit tests because the conversion tool from python2.6->
python3 can not work correctly all the time - so you need to test your
code.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane