Inconsistent formatting of decorators

[CiderMan]

Formatting of decorators does not appear to be consistent. Consider the following code snippet:

@atexit.register
def _writeback_cache():
    ...

Sometimes this is left unchanged and sometimes is reformatted with a space between the @ and the atexit.register. The reformatting seems to be stable for a single user and a single commit but differs between different users and different commit.

I have not been able to reproduce this reliably but, as an example, I did a big commit that blackened all files under a given directory and, if I run black on the same directory today, it would reformat 12 of the ~220 files due to this issue - including some that are unchanged since the commit that was supposed to blacken them...

• Version: black, version 20.8b1
• OS and Python version: Windows/Python 3.6.3

Does this bug also happen on master?

I've installed master in a venv and run it on the same directory as mentioned above. It would reformat 8 files, some of which were in the 12 that 20.8b1 would have formatted but some were not.

OK, I take that back. When I actually ran master on the codebase, the changes were due to hex literals now being converted to lower case, rather than upper case. The one decorator that had been changed to have a space due to this bug, was reformatted without a space.

Any idea when there is a new release planned on PyPI?

[JelleZijlstra]

There should be no space after the @. Could you give a specific example of code where black inserts a space?

[CiderMan]

Hi @JelleZijlstra, that's the thing, it is not the code being formatted that determines whether the space is indented, it appears to be something to do with the environment in which Black is invoked. When it adds the space, it adds it to all decorators within the file.

In fact, we yesterday discovered that, even for a single user on a single commit, if they run black from the command-line versus a task configured in their editor, they get different results - but the results appear consistent for a given invocation method.

As a result, although I have stated that this bug does not occur on master, it could be that I just happen to not to see the problem when invoked from the venv that I created and, were I to invoke it differently, I would still see it...

[CiderMan]

I've just started working on some code that runs under 3.8.7 and I've added a pre-commit hook to use Black with --check. However, I am now in a situation where the hook fails due to this bug but, when I run Black on the offending file, it says that the file is already black and is left unchanged. The only way I can commit is to use --no-verify on the git command-line - but I then lose all the other checks! I will have to remove this check until there is a fixed version of Black available on PyPI...

[JelleZijlstra]

Unfortunately you're not giving us much to come up with a fix. There might be some oddity in your environment, but there isn't enough information in this issue to reproduce the bug. Our code is supposed to never insert a space after @ in a decorator (https://github.com/psf/black/blob/master/src/black/__init__.py#L2254).

[ichard26]

I see @BillDenton and @StephenHillAtViaivi +1ed the OP. Apologies for the ping but does either of you have any information you could give us so we can try to debug this?

[CiderMan]

Hi @JelleZijlstra, I would love to provide more information for you to work with; I just not sure where to start. I'm happy to get stuck in (as I have on issue 1844) so, if you have any suggestions, I can try them out.

As I said, a quick test did not reproduce it with master so it is possible that it has already been fixed. Do you know when a new release is planned?

[CiderMan]

Our code is supposed to never insert a space after @ in a decorator (https://github.com/psf/black/blob/master/src/black/__init__.py#L2254).

I've just dug into this and it is interesting: that line was added in Sept 2020 so is not part of the current release. Looking at the pull request, I think that this line was added after the discussion starting:

I'm looking for help on the space after @ bug, I have no idea where this is added in the code.

Hence, I think that this bug has been reported (or, at least, was known about) previously and has been fixed on master.

Does anyone know when a new release will be made on PyPI?

[JelleZijlstra]

We made several new releases since the last comment. I'm going to assume this is now fixed, but feel free to reopen if you see similar behavior again.