Python 3.8 #650
Merged
Python 3.8 #650
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Hoikas
force-pushed
the
py3
branch
14 times, most recently
from
fc968c9 to
930d8ef
Compare
|
|
|
I have pushed a fix for the issue in which junked python.pak files are created by plPythonPack.exe. Using python.pak is still broken however due to changes in Python 3's import machinery... Work will continue on this. |
zrax
reviewed
May 15, 2020
Hoikas
force-pushed
the
py3
branch
3 times, most recently
from
81d0b7e to
c279f9c
Compare
|
Updated to fix issues from review and add proper PEP 451 compliant import machinery for python.pak. |
|
Rebased onto master, which now includes two commits that were previously part of this PR. See #651. |
Deledrius
reviewed
May 16, 2020
Closed
|
Reopening due to the merge of python 3.8 into vcpkg and successful testing of python.pak. |
Deledrius
requested changes
Jul 12, 2020
|
Updated to fix issues from review. |
Deledrius
approved these changes
Jul 13, 2020
|
Blocking on H-uru/PlasmaPrefix#4. |
This updates the C++ code for API changes in Python 3. Note that this does not attempt to fix issues like duplicated wide-string getter/setter functions.
Run 2to3 fixers: - unicode - dict - xrange - long Also manually fixed the abc metaclass usage to instead use `abc.ABC`.
Our CMake now exposes a "Scripts" target that will properly copy over all of the scripts including dat, SDL, Python, and Python stdlib from their corresponding location to the runtime output directory.
According to the Python documentation, calling `PyUnicode_AsUTF8AndSize` will cache a UTF-8 version of the python string for future use. So let's do that instead of reencoding UTF-16 or UTF-32 to UTF-8 each call to `PyUnicode_AsSTString`.
This is required due to reports from multiple testers that the client exits on loading StartUp. The issue is that Python 3 loads modules during its initialization--before we have installed our PEP 451 import machinery for python.pak. The previous code worked for us because we have Python 3 installed on our systems, which is not a reasonable assumption to have for our players. Python 3.8 adds APIs that allow us to initialize just the "core" and use the API, then initialize the interpreter itself once we have added the import machinery.
|
This looks ready to merge. Any objections? |
|
💥 💥 💥 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This updates the game engine and scripts to support Python 3. Note that the minimum required Python version is
3.73.8due to thebecause Python.pak support requires the new initialization API from 3.8. From my limited testing, the game plays correctly, however a full playthough was not done.PyUnicodeAPI changing to properly returnconst char*This changeset deletes the in-repo copy of the Python stdlib. We ought to not be versioning external code that changes based off the Python version. The stdlib and the rest of the scripts are now copied to the runtime output directory at build time. Hopefully this will make generating working game clients easier.
This DOES NOT:
update the resource.dat generation scripts to Python 3. Per @Deledrius and my experimentation, these rely on fragile modules that are nearly impossible to trivallypip installon Python 3.get[thing]W()methods in the Python APINote this extends the work done in #596 because it seems silly to replicate these changes on top of the other API changes found therein.