python3, and symbian(nokia phone) branches merged into pygame trunk

-
Over the last week two branches merged into the pygame trunk.

Lenard Lindstrom got his python3/python3.1 branch merged in.

Jussi Toivola had his symbian_s60 branch merged in to trunk.


Both ports do not have complete functionality yet... but both have most major modules working.

The python3 code has also been tested with the python3.1 beta release (there are small C API differences between both). Some of the work was based on stuff done by Marcus for his super-cool pgreloaded branch of pygame (which he is going to start doing some pre-releases of soon).

Pre-release builds for both pygame-python3.0, and pygame-symbian_s60 are available... search the mailing list for details. Both also build from subversion trunk.

Lenard got the python3 stuff ready quickly for a course a teacher is doing teaching python3 - part of the course uses pygame. So the pygame should work for his class.


We are hoping to release pygame1.9 in 3-4 weeks. Which means that there's about 1 week to get any last minute changes in. If they are new features, we will require docs/example, and tests... and it's probably too late to add any big features with an API larger than a function or two(unless the API has been discussed on the mailing list already).

The pygame1.9release is timed this way, so that we can get a release out around the time the GSOC coding period officially starts. The GSOC students can be involved in a release, and we can devote more time to their new projects after the release is out. We should also have a good version ready for python3.1 whose release schedule says it is to be released in 6-7 weeks (June 27th).

If any python3 developers want to help us improve our python3.1 support - please get in contact with the mailing list.

Comments

Unknown said…
This is excellent news!

We teach Python as a first language to CS students at the University of Leeds, and one of the things that has prevented us from embracing version 3 is the fact that we use Pygame in our teaching.

If there's anything we can do to help with getting Pygame established on Python 3.x, do let us know.
9:49 AM
René Dudfield said…
Hi Nick,

nice to hear about your course.

If you feel like helping to write some unittests there's some that need finishing :)

All the test stubs are filled in... they just need the body of the test done.

Otherwise feedback on the release candidates would be grand. There will probably be 3 release candidates before the final one is released.

Or try running your code with the python3 version of pygame... and send your experiences to the mailing list.



cheers!
12:29 PM
Post a Comment

Popular posts from this blog

Draft 3 of, ^Let's write a unit test!^

-
Image
So, I started writing this for people who want to 'contribute' to Community projects, and also Free Libre or Open source projects. Maybe you'd like to get involved, but are unsure of where to begin? Follow along with this tutorial, and peek at the end in the "what is a git for?" section for explanations of what some of the words mean. Draft 1, 2018/07/18 - initial draft. Draft 2, 2019/11/04 - two full unit test examples, assertions, making a pull request, use python 3 unittest substring search, "good first issue" is a thing now. Started "What is a git for? Jargon" section. Draft 3, 2020/12/12 - default branch name is main. What's first? A test is first. A unit test is a piece of code which tests one thing works well in isolation from other parts of software. In this guide, I'm going to explain how to write one using the standard python unittest module, for the pygame game library. You can apply this advice to most python pr
Read more

Is PostgreSQL good enough?

-
Image
tldr; you can do jobs, queues, real time change feeds, time series, object store, document store, full text search with PostgreSQL. How to, pros/cons, rough performance and complexity levels are all discussed. Many sources and relevant documentation is linked to. Your database is first. But can PostgreSQL be second? Web/app projects these days often have many distributed parts. It's not uncommon for groups to use the right tool for the job. The right tools are often something like the choice below. Redis for queuing, and caching. Elastic Search for searching, and log stash. Influxdb or RRD for timeseries. S3 for an object store. PostgreSQL for relational data with constraints, and validation via schemas. Celery for job queues. Kafka for a buffer of queues or stream processing. Exception logging with PostgreSQL (perhaps using Sentry) KDB for low latency analytics on your column oriented data. Mongo/ZODB for storing documents JSON (or mangodb for /dev/null replacemen
Read more

post modern C tooling - draft 6

-
Image
Contemporary C tooling for making higher quality C, faster or more safely. DRAFT 0 - 10/11/18,  DRAFT 1 - 9/16/19, 7:19 PM, I'm still working on this, but it's already useful and I'd like some feedback - so I decided to share it early. DRAFT 2 - 10/1/19, mostly additions to static analysis tools. DRAFT 3 - 10/4/19, updates on build systems, package management, and complexity analysis.  DRAFT 4 - 10/6/19, run time dynamic verification and instrumentation, sanitizers (asan/ubsan/etc), performance tools, static analyzers. DRAFT 5 - C interpreter(s).  DRAFT 6 - 11/6/19 , mention TermDebug vim,  more windows debugging tools, C drawing for intro. In 2001 or so people started using the phrase "Modern C++". So now that it's 2019, I guess we're in the post modern era? Anyway, this isn't a post about C++ code, but some of this information applies there too. No logo, but it's used everywhere. Welcome to the post modern era. S
Read more