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

chore: cleanup types #1263

Merged
merged 1 commit into from Sep 16, 2022
Merged

chore: cleanup types #1263

merged 1 commit into from Sep 16, 2022

Conversation

henryiii
Copy link
Contributor

@henryiii henryiii commented Sep 8, 2022

PyLance doesn't like raw Final (and Tuples hard-code the length if you don't specify it).

Moved to #1270 to unblock this:

Also moved to raising SystemExit over sys.exit. Doesn't require an import & is just the implementation of sys.exit anyway. See python: raise SystemExit (beginner - intermediate).

Copy link
Contributor

@joerick joerick left a comment

Choose a reason for hiding this comment

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

I like the stronger Final types - I have also been enduring PyLance errors for these!

But I'm kinda -0 on most of the raise SystemExit changes. I've watched the video and I get it, but it just seems a little 'clever' to me. Importing sys isn't bad, and it can be useful information - the absence of a sys import is actually quite a useful signal to me that a Python file doesn't interact with the system and is more likely to be pure.

I'm -1 on uses of raise SystemExit(0), as these look like errors and that isn't how they're intended to be read.

Comment on lines 27 to 29
raise SystemExit(
subprocess.run([sys.executable, "-m", "cibuildwheel"], cwd=project_dir).returncode
)
Copy link
Contributor

Choose a reason for hiding this comment

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

This is poor form, IMO. I watched the video and follow the logic, but sys.exit is more idiomatic to me. The raise implies an error. I realise that the exception is how Python works internally, but I believe that it does that to conveniently reuse the try/finally semantics, and not because it should be viewed as an error. It comes across strangely in the case that this is raise SystemExit(0) - there, the program is exiting successfully but our code is raising an exception.

More familiar is a function that never returns, like C's exit(). That's also how most (all?) other mainstream languages do it, e.g. Rust, Ruby, Node.js, Java, Go...

@@ -211,7 +211,7 @@ def build_in_directory(args: CommandLineArguments) -> None:
if args.print_build_identifiers:
for identifier in identifiers:
print(identifier)
sys.exit(0)
raise SystemExit(0)
Copy link
Contributor

Choose a reason for hiding this comment

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

Also not super fond of this...

Signed-off-by: Henry Schreiner <henryschreineriii@gmail.com>
@henryiii henryiii changed the title chore: cleanup types & exits chore: cleanup types Sep 16, 2022
@henryiii henryiii merged commit 00b2600 into pypa:main Sep 16, 2022
@henryiii henryiii deleted the henryiii/chore/cleanup branch September 16, 2022 15:05
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

2 participants