[pygame] goodbye SDL1, python 2.7/3.5?

16 views
Skip to first unread message

René Dudfield

unread,
Oct 9, 2021, 3:43:25 AM10/9/21
to pygame...@seul.org
hey hey,

so, we've been talking about stopping support for these for a _while_.
Should the next pygame release 2.0.2 be the last one that supports them?
That means the pygame 2.1.0 series will be without SDL1 and py2 support.


---

There's still lots of python 2.7 pygame users. Maybe more than mac users for example.
But it's at least not increasing anymore, like it was only six months ago (near the number of python 3 users... yes really).

We get a cleaner code base, but also get to use modern C (or is it post modern C?). Mainly because python 2.7 on windows has to use an ancient compiler that doesn't support even all of C89. This means things like variable declarations anywhere we want, and better const/struct/union handling. Also a lot fewer ifdefs, and compatibility hacks.

3.5 was EOL'd about a year ago, and not so many people use it.
With 3.6 being the minimum supported python, we'd also get to use contemporary python. Things like types, and even module level getattr.

Probably it could be done in this order.
- ripping out SDL1 (there's a PR for that already)
- ripping out pre-3.6 isms (mostly removing 2.x compat stuff).


What about previous users? SDL1, and python 2.7 users have access to previous releases. They aren't going anywhere. New features, and bug fixes would be a problem of course. The Debian universe is still on pygame 1.9.6 for example. A lot of people will just keep using that.



There's some discussion on gh here:


Nicholas H.Tollervey

unread,
Oct 9, 2021, 6:50:56 AM10/9/21
to pygame...@seul.org
René,

Change is constant.

ποταμοῖσι τοῖσιν αὐτοῖσιν ἐμβαίνουσιν ἕτερα καὶ ἕτερα ὕδατα ἐπιρρεῖ

(On those who enter the same rivers, ever different waters flow)

+1 to 2.1.0 sans SDL1 and Python2.

:-P

Big hugs!

N.

On 09/10/2021 08:43, René Dudfield wrote:
> hey hey,
>
> so, we've been talking about stopping support for these for a _while_.
> Should the next pygame release 2.0.2 be the last one that supports them?
> That means the pygame 2.1.0 series will be without SDL1 and py2 support.
>
>
> ---
>
> There's still lots of python 2.7 pygame users. Maybe more than mac users
> for example.
> But it's at least not increasing anymore, like it was only six months
> ago (near the number of python 3 users... yes really).
> https://github.com/pygame/pygame/issues/2326
> <https://github.com/pygame/pygame/issues/2326>
>
> We get a cleaner code base, but also get to use modern C (or is it post
> modern C?). Mainly because python 2.7 on windows has to use an ancient
> compiler that doesn't support even all of C89. This means things like
> variable declarations anywhere we want, and better const/struct/union
> handling. Also a lot fewer ifdefs, and compatibility hacks.
>
> 3.5 was EOL'd about a year ago, and not so many people use it.
> With 3.6 being the minimum supported python, we'd also get to use
> contemporary python. Things like types, and even module level getattr.
>
> Probably it could be done in this order.
> - ripping out SDL1 (there's a PR for that
> <https://github.com/pygame/pygame/pull/2692> already)
> - ripping out pre-3.6 isms (mostly removing 2.x compat stuff).
>
>
> What about previous users? SDL1, and python 2.7 users have access to
> previous releases. They aren't going anywhere. New features, and bug
> fixes would be a problem of course. The Debian universe is still on
> pygame 1.9.6 for example. A lot of people will just keep using that.
>
>
>
> There's some discussion on gh here:
> https://github.com/pygame/pygame/issues/2326
> <https://github.com/pygame/pygame/issues/2326>
>
>

OpenPGP_signature

Michael Lutynski

unread,
Oct 9, 2021, 5:09:04 PM10/9/21
to pygame...@seul.org

I read through the thoughtful discussion on GitHub and I wouldn't even imagined some of the factors, like XP in China, but it seems like the right thing to do, as people will still have access to py2 and sdl1.

 

 

~ Michael



On Saturday, October 9, 2021 12:43:08 AM PDT you wrote:

> hey hey,

>

> so, we've been talking about stopping support for these for a _while_.

> Should the next pygame release 2.0.2 be the last one that supports them?

> That means the pygame 2.1.0 series will be without SDL1 and py2 support.

>

>

> ---

>

> There's still lots of python 2.7 pygame users. Maybe more than mac users

> for example.

> But it's at least not increasing anymore, like it was only six months ago

> (near the number of python 3 users... yes really).

> https://github.com/pygame/pygame/issues/2326

>

> We get a cleaner code base, but also get to use modern C (or is it post

> modern C?). Mainly because python 2.7 on windows has to use an ancient

> compiler that doesn't support even all of C89. This means things like

> variable declarations anywhere we want, and better const/struct/union

> handling. Also a lot fewer ifdefs, and compatibility hacks.

>

> 3.5 was EOL'd about a year ago, and not so many people use it.

> With 3.6 being the minimum supported python, we'd also get to use

> contemporary python. Things like types, and even module level getattr.

>

> Probably it could be done in this order.

> - ripping out SDL1 (there's a PR for that

signature.asc

Daniel Pope

unread,
Oct 10, 2021, 7:15:13 AM10/10/21
to pygame-users
On Sat, 9 Oct 2021, 08:43 René Dudfield, <ren...@gmail.com> wrote:
so, we've been talking about stopping support 

Yes, please! SDL1 is past its useful lifespan and was the cause of various weird window problems that just went away with SDL2.

I believe package tags can indicate that a package is not compatible with Python 2 but for good measure we should sabotage setup.py so that it refuses to do anything under Python 2.

Python 3.6 is end of life by the end of the year so we could drop support for that for good measure. https://devguide.python.org/

My big/growing bugbear is with pygame.mixer/SDL_mixer. I'm really glad you've fixed the MP3 support in 2.0.2dev4 but I don't think the underlying library is good at all - no procedural sounds, spatial audio, HRTFs, and sound buffers can't have variable formats (you can't supply a mono sound buffer when the mixer is set to stereo).

If we're thinking of big, big changes, maybe we could build a laundry list of them and jump to PyGame 3.0?

Sam Bull

unread,
Oct 10, 2021, 9:15:57 AM10/10/21
to pygame...@seul.org
On Sat, 2021-10-09 at 09:43 +0200, René Dudfield wrote:
> Things like types, and even module level getattr.

I've not had time to look into pygame for a while now. But, I've been thinking about
experimenting with an asyncio implementation of pygame at some point in the future.

I'd also really like to see typing, and can atleast find the time to help review any
typing PRs when someone gets to that (I've sorted out typing on several other projects
already).
This also opens up the possibility to compile the code using mypyc, potentially
allowing us to optimise more code without having to hand-write any C code (it would also
be worth benchmarking against the existing C code to see if it's possible to replace it
with no performance penalty).

Thanks,
Sam
signature.asc

Daniel Pope

unread,
Oct 10, 2021, 6:23:55 PM10/10/21
to pygame-users
On Sun, 10 Oct 2021, 14:16 Sam Bull, <pyg...@sambull.org> wrote:
I've been thinking about
experimenting with an asyncio implementation of pygame at some point in the future.

I have written that[1]; it works very well[2].

I'm assuming you mean async not asyncio. Asyncio is kind of at a dead end. All the good Python async ideas are in Trio.

Reply all
Reply to author
Forward
0 new messages