Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python 2-3 compatible utility scripts #530

Closed
wants to merge 6 commits into from

Conversation

jclc
Copy link
Contributor

@jclc jclc commented Apr 18, 2018

The shebang #!/bin/env python is meant to point to python2 but some systems have it point to the newer and preferable python3, making these scripts fail when run without explicitly invoking Python. Since util/generate_docs.py already requires python3, it shouldn't be an issue to migrate all the scripts to the newer version. Removed unused imports and __future__ imports as well.

Building libuv still requires python2 due to its build system, but there is some momentum to migrate it to python3.

@jclc
Copy link
Contributor Author

jclc commented Apr 19, 2018

On second thought, I'll consider making them python2-3 compatible. Although python3 is the future (should've been the present for years now) it's probably better to only require python2 for now rather than both versions.

@jclc
Copy link
Contributor Author

jclc commented Apr 30, 2018

Ironically, the bit where the code actually checked which version of Python was running was causing compatibility issues.

@jclc jclc changed the title Update utility scripts to Python 3 Python 2-3 compatible utility scripts Apr 30, 2018
System.print("two")

// Generate a compile error so we can test that the line number is correct.
+ * // expect error

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this file has been commited by mistake.

Copy link
Contributor Author

@jclc jclc May 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it used to have carriage returns right before newlines, which confused Python into thinking they were CRLF-newlines in utils/test.py. Since then I made it open the files as binary to circumvent that, so I suppose it doesn't really make much of a difference.

Looking at the original file now, my editor may have converted the CRs to CRLFs on its own before I checked it with a hex editor.

@ruby0x1
Copy link
Member

ruby0x1 commented Sep 18, 2019

This seems to have been superseded by #541, closing.

@ruby0x1 ruby0x1 closed this Sep 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants