Blackify some files to show style differences

[jfuss]

Issue #, if available:
N/A

Description of changes:
This PR is meant to show what the differences would be if we started to use Black. A good read about benefits and tradeoffs can be found under the Django dep project (dep 0008).

Happy to have a formal write up but wanted to show how this could look in our codebase through a small PR. If the team decides that this is worth while, I can work on formalize this with pre-commit hooks to ensure formatting is always done and therefore we should no longer need to care about formatting :). We could do something similar to how the attrs project is using Black.

Checklist:

• Write Design Document (Do I need to write a design document?)
• Write unit tests
• Write/update functional tests
• Write/update integration tests
• make pr passes
• Write documentation

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[sanathkr]

Orange is the new black!

[sriram-mv]

Overall I like it. 👍

[sriram-mv]

Shall we adopt this? Given the line length is configurable, I'm okay with us taking this on.

[jfuss]

I haven't heard a strict no yet. There is still some work to do here and we need to figure out a good time to do the flip. I am hoping to have this ready sometime early next week.

[jfuss]

This should be ready to go.

PR includes:

• the current HEAD of development in formatted
• updated DEVELOPMENT_GUIDE with instructions on installing black and or pre-commit
• updated Makefile with a target to run the formatter
• travis running black --check to make sure source code is black compliant
• Integrated with pre-commit for those who want to run git hooks with black
• Integrated with pyproject.toml to hold our black config. More info in PEP518

[sanathkr]

Can you also exclude init template directories?

[jfuss]

good idea. sure can do.

[jfuss]

I have excluded the templates used for sam init. I will un-format them once, I do the update from develop and rerun black dance.

[sanathkr]

remove empty lines

[jfuss]

done

[sanathkr]

call it just black?

[jfuss]

sure

[sanathkr]

remove py27?

[jfuss]

I kept it because we still have py27 support :(. So wasn't comfortable making formatting related this and risk breaking it. I just quickly ran it and the only changes were removing u from strings like u"help". For now, I would prefer to just leave it.

[sanathkr]

make black instead?

[jfuss]

make black will format the files are write it back to the filesystem. Instead this commands black --check makes sure that the files are formatted and if not the build will fail. This ensures our codebase is always formatted. I can create a make black-check? command or something. I thought about putting it in make pr but didn't want to go through the hassle of pip installing on appveyor too (you can only [pip] install black in 3.6 or above).

[sriram-mv]

I wonder if we should run make black on a github post hook or something and completely forget about formatting. it gets auto taken care of.

[viksrivat]

If we run it as a github post hook, do we still need to run make lint/flake ?

[jfuss]

| I wonder if we should run make black on a github post hook or something and completely forget about formatting. it gets auto taken care of.

@thesriram That is what the pre-commit installation instructions are for. I didn't want to make it required. I don't like pip installing other tools, because it can mess with the global or user installation on a system. So I made this optional but travis does run a check to ensure the files are 'blackified', so we should never be checking in code that is not formatted.

| If we run it as a github post hook, do we still need to run make lint/flake ?

@viksrivat I think we can remove flake8, but would like to keep pylint around until we know black handles everything.

[sriram-mv]

Appveyor

[jfuss]

done

[sriram-mv]

Not sure why these random empty lines show up here, github formatting?

[jfuss]

I don't see any empty lines in the diff. Must be github?

[sanathkr]

Why isn't black run as part of make pr?

[jfuss]

the make black command requires you to commit the changes. So I didn't want the make pr to run that and make it look like it works. I can add another make command that does the check instead, which is probably what we want anyways.

[jfuss]

If you install the git hooks, running the check on pr is just redundant. This is because you can't push unless black passes.

[sanathkr]

LGTM as long as CI passes ⬛️🏴