Clean up python file handling - #1268
Conversation
scarletcafe
left a comment
scarletcafe
left a comment
There was a problem hiding this comment.
Ironically PEP 686 means this behaviour will be default as of a month from now anyway but it's always good to be explicit.
|
oh that's good to hear because the current behavior is stupid, also really funny timing, but of course even then it'd be good to support python versions before 3.15 |
|
Thanks for doing this! It looks like there's one file that needs a formatting fix according to black - do you mind doing that? |
|
🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀🚀 This PR matches 71 functions (+0.77%) on |
|
How do I fix this? |
There was a problem hiding this comment.
Based on what the closest env I can get to what it's using reports, it's just complaining about the single quote usages here.
The GHA should probably be changed to use black --diff instead of black --check, and the Python version should be bumped up from 3.8 since it's EOL.
Co-authored-by: Devon R <8049998+scarletcafe@users.noreply.github.com>
|
Thanks |
|
Can this be merged? |
4 participants
While working on windows support for dx, i found that lots of python code doesn't explicitly specify an encoding when calling
open, which causes an issue on windows where it defaults to cp1252 for some reason. This also made me find some instances offile.close()being called explicitly and lots of instances of"r"being omitted (which can be confusing because it's not immediately clear what python's default behavior is in this case).While the encoding changes aren't technically necessary here as the decomp doesn't support non-WSL windows, it is still good to have.