Hm... It's actually hard to point to one thing and say "this is why you should switch to Python 3." In general, Python 3 is a cleaner and better-designed language than Python 2, in many relatively subtle ways. It removes a lot of obsolete ways of doing things, replacing them with ways that are now preferred, given maybe 10 years of experience with Python 2.
In Ren'Py's case, it's largely "switch or get left behind". Once Python 3 comes out, Python 2 is going to be less and less maintained, with new features going into 3 only. So while I don't plan to be the first to switch, I do want to get while the getting is good, while there's still a huge base of experience with the transition.
Ren'Py-based example... It's generally much easier to port a game ever couple of months from 6.5.0 to 6.6.0 to 6.6.1 to 6.6.2 to 6.6.3 to 6.7.1 in steps than it is to try to go from 6.5.0 to 6.7.1 in one big jump. For example, back in February, there was a lot of experience with dealing with the new layout system, and changing your code to work with it. Nowadays, that experience is less fresh on people's minds, and we'd have to look things up to support it.
I'm firming up my plans for the future now. Right now, it looks like this:
- In the next release: I'm going to change the text tags syntax. The { character we use is being taken over by the new-style string interpolation, so I'm going to have to pick a new character to introduce Ren'Py text tags. I'm wavering back and forth between html-style (<tag>) and phpbb style ([tag]), with html-style having a slight lead simply because it's easier to post examples on the forum. (But less simple to post on the wiki, sigh.)
The old text tags will still be supported, for the time being, but might trigger a subtle lint warning.
- Once 2.6 is ready (and by ready, I mean that all of the libraries and such I use work without trouble): I will port Ren'Py to Python 2.6. There will be an optional flag to enable the new string interpolation syntax, while the old one will remain supported for the time being.
The new string interpolation syntax will allow things like:
Code: Select all
e "Hey, {player}, can you scan that {monster.name} for me?"
p "Yeah, the {monster.name} has {monster.hp} hit points left!"
We will drop unofficial support for Windows 98 and ME at this time. They've already been officially unsupported for a while now, but I suspect Ren'Py will still work on them anyway.
- Once Python 3 is ready, and I don't expect this to be for a while yet, since there still needs to be performance improvements done to it: I will port Ren'Py to Python 3. The old string interpolation syntax will be dropped entirely, and the new one will be the default, meaning that the old text tags will also be unsupported.
This will correspond to a major release of Ren'Py, either 7 or 8. The previous major release (6 or 7) will continue to be maintained for the time being, but no new features will be ported to it. I will be strongly encouraging people to move their games to the latest Ren'Py.
Thankfully, that should be fairly easy. While there are a lot of changes in Python 3, I don't think many of them really matter insofar as Ren'Py games are concerned. So I'd think 90% of the games would work simply by running them, and maybe the other 10% might require minor changes. I am worried I will have to drop .rpyc and -LT-1.save compatibility, which means that we will need the .rpy files to port the game up to Ren'Py-future. (We've been .rpyc compatible since early 2006.)
- Eventually, Ren'Py-present will be very obviously obsolete, and I won't be supporting it for new games, even long ongoing ones. I do plan to support it for older games, but without new features and platform support. (It may or may not run on Windows 8, and I'm not sure it's my concern either way. Windows 7 should be supported.)
I may use Ren'Py-future to get rid of some older features, like the layout.compat() mode, which will be more than a year obsolete by then.
