Skip to content

Conversation

@marc-hb
Copy link
Collaborator

@marc-hb marc-hb commented Mar 4, 2022

3 commits
2 commits

@marc-hb
Copy link
Collaborator Author

marc-hb commented Mar 5, 2022

sof-ci/jenkins is down for the week-end

Copy link
Contributor

@aborisovich aborisovich left a comment

Choose a reason for hiding this comment

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

Good refactor in general, only some remarks related to the comments wording and that exception catching.

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 this is bad.
First of all, catching a BaseException is a work-around to silence pylint. It does not fix what the warning actually means in the warning message. Second, what is much more dangerous - I believe that in this operation Win32 exception may occur that is not BaseException and even not Exception derived and I think general "except" statement handles it but nothing else. Correct me if I am wrong but I gave it at lot of thought to this line writing this.
Can we just silence pylint in this case and add a comment about Win32 exception?
Adding a symlink in Windows is quite non-standard operation in my opinion.
I found in this thread that you can just do except Exception: # pylint: disable=broad-except .

I do not know what system API Python uses but some references to WinAPI symbolic link programming considerations makes me somewhat uneasy. Maybe I am overreacting. If somebody is willing to verify this on Windows please do and correct me, otherwise I would leave that "all catch" as is.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

First of all, catching a BaseException is a work-around to silence pylint.

I didn't even run pylint, I just spotted this code first without pylint and then I googled the pylint warning. This sort of catch-all is bad in any language, so I knew pylint would have a warning for this and a better "commit message" than me. Every linter will flag this in any language.

Correct me if I am wrong but I gave it at lot of thought to this line writing this.

I wasn't aware of these complexities. Silencing a warning makes sense only when there is comment that explains why + makes sure all your thoughts don't get lost!

I found in this thread that you can just do except Exception: # pylint: disable=broad-except .

I'm not familiar enough with Windows to test this. I will drop this commit from this PR. Could you submit this when you get a chance?

PS: this script has 261 pylint warnings right now.

Your code has been rated at -1.26/10

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah I will check asap that exception.

PS: this script has 261 pylint warnings right now.
Your code has been rated at -1.26/10

Well, it's not surprising given that this code was rewritten from bash script and not designed from scratch the "pythonic" way :/

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Well, it's not surprising given that this code was rewritten from bash script and not designed from scratch the "pythonic" way :/

The vast majority of the pylint warnings are about indentation or mix of tabs and spaces. The second most frequent are about naming style.

Copy link
Contributor

Choose a reason for hiding this comment

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

Then looks like I need to improve my python styles, Installed pylint just now so expect improvements hoho!

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Then looks like I need to improve my python styles, Installed pylint just now so expect improvements hoho!

:-)

I think your coding style is fine, some of pylint choices are subjective, especially wrt. whitespace. I think there's a way to override some of them, maybe with a header. Please go easy on the whitespace, I have work in progress and others might have too! So I would prefer a header.

marc-hb added 2 commits March 10, 2022 02:09
A second git_submodules_update() immediately after the first one does
not make sense. This looks like something leftover from a past
experiment.

Fixes initial commit 1de3ef3 ("Rewritten xtensa-build-zephyr.sh to
python")

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
De-duplicate this code:

	if args.platforms:
		build_platforms()
		show_installed_files()

Signed-off-by: Marc Herbert <marc.herbert@intel.com>
@marc-hb marc-hb marked this pull request as ready for review March 10, 2022 02:18
@marc-hb marc-hb requested a review from aborisovich March 10, 2022 02:18
@marc-hb marc-hb dismissed aborisovich’s stale review March 10, 2022 02:19

Comments reworded, please review again

@marc-hb marc-hb requested a review from kv2019i March 10, 2022 02:19
@lgirdwood lgirdwood merged commit 7a847a5 into thesofproject:main Mar 10, 2022
@marc-hb marc-hb deleted the dedup-zephyr-py branch March 11, 2022 02:35
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