Skip to content

[build-script] Move some calculations into independent methods. #23865

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

Conversation

drodriguez
Copy link
Contributor

Move the calculations of platforms_to_skip_build, platforms_to_skip_test, platforms_archs_to_skip_test, and platforms_to_skip_test_host to their own independent functions. Each function deal with one of them and they are pure functions, which should improve readability a little.

This commit is part of #23810 which was reverted in #23861. This commit only deals with a split of a large method into smaller function in the context of BuildScriptInvocation.

This was part of #23257. I’m trying to split the PR in smaller ones to make the reviews easier. Other PRs in this group are #23303, #23803, #23810, and #23822.

Move the calculations of platforms_to_skip_build, platforms_to_skip_test, platforms_archs_to_skip_test, and platforms_to_skip_test_host to their own independent functions. Each function deal with one of them and they are pure functions, which should improve readability a little.
@compnerd
Copy link
Member

compnerd commented Apr 8, 2019

@swift-ci please test

self.platforms_to_skip_build = set()
self.build_libparser_only = args.build_libparser_only

def __platforms_to_skip_build(self, args):
Copy link
Contributor

@Rostepher Rostepher Apr 9, 2019

Choose a reason for hiding this comment

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

Nitpick: I think the Python standard for "private" methods is to prefix with a single _ character. Certainly not a big issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

One underscore is a “agreement” of a non-public API, but completely accessible. At least two underscores (and not finishing in more than one underscore) will ask the Python interpreter to mangle the name, becoming a little bit more “private” (but the mangling scheme is quite simple, so still accessible).

(Ref: https://docs.python.org/2.7/tutorial/classes.html#private-variables-and-class-local-references)

In this case in particular, it doesn’t matter that much which one to use (anything that indicates “don’t call this” should be fine), but in other cases (specially when inheritance is involved), the two underscores avoids name clashing problems.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think I remember seeing something along these lines a long time ago, but I totally forgot. That's a pretty cool feature! I'm totally fine with keeping these names then considering these are implementation details.

Copy link
Contributor

@Rostepher Rostepher left a comment

Choose a reason for hiding this comment

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

LGTM!

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.

3 participants