Black code formatter

I setup black in virtualEnv and everything appears to be working. It is however changing source code dramatically. e.g.

actions.py

Before

'''
This class does most of the heavy lifting in processing messages from the UI client.
'''
class Actions(MakesmithInitFuncs):

    Device.pin_factory = MockFactory()

    def processAction(self, msg):
        '''
        When a message comes in via the UI client it gets parsed and processed here.
        :param msg: json of message from UI client
        :return:
        '''
        try:
            # Commands allowed during sending gcode.  These commands won't screw something up.
            if msg["data"]["command"] == "createDirectory":
                if not self.createDirectory(msg["data"]["arg"]):
                    self.data.ui_queue1.put("Alert", "Alert", "Error with creating directory.")
            elif msg["data"]["command"] == "stopZ":
                if not self.stopZ():
                    self.data.ui_queue1.put("Alert", "Alert", "Error with stopping Z-Axis movement")
            elif msg["data"]["command"] == "stopRun":

After

"""
This class does most of the heavy lifting in processing messages from the UI client.
"""


class Actions(MakesmithInitFuncs):

    Device.pin_factory = MockFactory()

    def processAction(self, msg):
        """
        When a message comes in via the UI client it gets parsed and processed here.
        :param msg: json of message from UI client
        :return:
        """
        try:
            # Commands allowed during sending gcode.  These commands won't screw something up.
            if msg["data"]["command"] == "createDirectory":
                if not self.createDirectory(msg["data"]["arg"]):
                    self.data.ui_queue1.put(
                        "Alert", "Alert", "Error with creating directory."
                    )
            elif msg["data"]["command"] == "stopZ":
                if not self.stopZ():
                    self.data.ui_queue1.put(
                        "Alert", "Alert", "Error with stopping Z-Axis movement"
                    )
            elif msg["data"]["command"] == "stopRun":

Do I have to do something to configure black or is the source code in repo just not formatted using it?
If the latter then how should we go about doing a source code formatting change this big?

please look at configuring black, git won't know that it's formatting and will change all the files when you submit them (making a mess for everyone else) it looks like the key change is going to be in allowing longer lines (possibly something about inlining parameters) David Lang

Read up on black and see that it supports using a pyproject.toml for configuration. Here is one I rolled.

pyproject.toml

[tool.black]
line-length = 120
skip-string-normalization = true
target-version = ['py36', 'py37', 'py38']
include = '\.pyi?$'
exclude = '''
/(
    \.eggs
  | \.git
  | \.hg
  | \.mypy_cache
  | \.tox
  | \.venv
  | _build
  | buck-out
  | build
  | dist
  # The following are specific to Black, you probably don't want those.
  | blib2to3
  | tests/data
  | profiling
)/
'''

skip-string-normalization = true stops it from replacing all single quotes with double quotes.
line-length = 120 set max line length. Don't know what sane value this should use. The default is 88 and in other languages the max I have seen is 90.

After toml

'''
This class does most of the heavy lifting in processing messages from the UI client.
'''


class Actions(MakesmithInitFuncs):

    Device.pin_factory = MockFactory()

    def processAction(self, msg):
        '''
        When a message comes in via the UI client it gets parsed and processed here.
        :param msg: json of message from UI client
        :return:
        '''
        try:
            # Commands allowed during sending gcode.  These commands won't screw something up.
            if msg["data"]["command"] == "createDirectory":
                if not self.createDirectory(msg["data"]["arg"]):
                    self.data.ui_queue1.put("Alert", "Alert", "Error with creating directory.")
            elif msg["data"]["command"] == "stopZ":
                if not self.stopZ():
                    self.data.ui_queue1.put("Alert", "Alert", "Error with stopping Z-Axis movement")
            elif msg["data"]["command"] == "stopRun":
                if not self.stopRun():
                    self.data.ui_queue1.put("Alert", "Alert", "Error with stopping run")
            elif msg["data"]["command"] == "pauseRun":
                if not self.pauseRun():
                    self.data.ui_queue1.put("Alert", "Alert", "Error with pausing run")
            elif msg["data"]["command"] == "resumeRun":

Should we include the toml file in the project. Do you have an existing one that you are using.

On Wed, 22 Jan 2020, gb0101010101 wrote: Read up on `black` and see that it supports using a `pyproject.toml` for configuration. Here is one I rolled. `skip-string-normalization = true` stops it from replacing all single quotes with double quotes. `line-length = 120` set max line length. Don't know what sane value this should use. The default is 88 and in other languages the max I have seen is 90.

we haven't set a standard, I like 120 (and sometimes go longer) we aren't limited to 80 column vt100 terminals any longer, and with a language that uses tabs for flow control, I think you need more than 80-90 characters for real-world programming (otherwise you end up creating functions that are only called once just to work around indentation/line length limits) but my stance on coding standards is that while everyone has a preference, it's more important to define a standard and stick with it than what the details of the standard are. I understand python has pretty significant defaults that everyone is encouraged to comply with (unlike other languages that have more options), so other than not changing quotes and lengthening the lines, I'm good with whatever the defaults are. @madgrizzle, this started as your project, so speak up if you have any dtrong preferences.

Should we include the toml file in the project. Do you have an existing one that you are using.

I am not up on common tools for python formatting (I generally just use vi for my programming), but if this is a very common tool, I think it would be a good idea to include it. I would suggest that you make one commit that reformatted all code using this tool rather than letting it make it's changes file by file as you touch them for other reasons. Include the toml file in this commit (and if there are other tools that are commonly used, if we can include the equivalent file for them as well, that would be fantastic) David Lang

I am fine with 120 line length as most IDEs provide enough space in the editor window when using default layouts. But I'm a complete noob to Python.

I have read that Python Devs are VERY picky about code format. e.g. Using double quotes instead of single. black makes it difficult to override many setting purely to force the same coding style. Looking at the code in Python Libraries; all of it seems to be using stock black settings as show in OP After sample.

I generally just use vi for my programming

There is a black plugin for vim

I would suggest that you make one commit that reformatted all code using this
tool

Yes completely agree. I would rather not do it and have it come straight from this project using a unique version number in case things go horribly wrong.

Here's a test branch with changes using stock black setting just updating Actions/*.py
(1,704 additions and 760 deletions.)
gb0101010101/WebControl@master...gb0101010101:gb0101010101-test-black-stock

And here's another using the toml settings. (681 additions and 609 deletions.)
gb0101010101/WebControl@master...gb0101010101:gb0101010101-test-black-toml

Still masses of changes.

So johnboiles recommended using black and I did use it for a while, but it bothered me with all the line breaks and I really haven't used it since.

Well I am all for a defined coding format. Black seems to format they way most Python projects do. It may be annoying at first but it will greatly help in the long run.

Since we only have a few people committing changes right now it seem like a good time to format the code. I can do it and test if you want.

One problem I have is that I code on multiple machines.. sometimes on an RPI. some times on my desktop, sometimes on my laptop. I think only that laptop has black.. so I'd need to figure things out for the other two (i.e., get black installed) before I could keep up with it.

On Mon, 27 Jan 2020, madgrizzle wrote: One problem I have is that I code on multiple machines.. sometimes on an RPI. some times on my desktop, sometimes on my laptop. I think only that laptop has black.. so I'd need to figure things out for the other two (i.e., get black installed) before I could keep up with it.

once everything is reformatted to a standard, just make the new code look like the code around it on your other machines :-) long-term, we can have the testing complain if code isn't formatted correctly (and possibly just reformat it, but I'm leery about that, especilly with python, code that isn't formatted correctly may not be working as intended) David Lang

@madgrizzle

@madgrizzle One problem I have is that I code on multiple machines

Black is a Python plugin so runs on everything that Python does. On Rpi just do
pip install black
But real question is why are your coding on RPi? Are you using an IDE or CLI editor? Some CLI editors like VIM also support Black (mentioned in previous comment)

@davidelang code that isn't formatted correctly may not be working as intended

Right, This could cause problems when doing a large scale code format commit. This is what I was offering to test. Though the testing I was thinking of is for code errors rather than functionality.

I have a controller hooked to my rpi and sometimes I just use notepad++ to edit files via ssh because I can't hook a controller up to the machine I'm using at the moment.

I'm not against black.. just haven't gotten all setup for it.

Navigation Menu

Repository navigation

Black code formatter #82

actions.py

Before

After

pyproject.toml

After toml

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Black code formatter #82

Description

actions.py

Before

After

Activity

davidelang commented on Jan 23, 2020

gb0101010101 commented on Jan 23, 2020

pyproject.toml

After toml

davidelang commented on Jan 23, 2020

gb0101010101 commented on Jan 23, 2020

madgrizzle commented on Jan 23, 2020

gb0101010101 commented on Jan 27, 2020

madgrizzle commented on Jan 27, 2020

davidelang commented on Jan 27, 2020

gb0101010101 commented on Jan 28, 2020

madgrizzle commented on Jan 28, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions