Black: Black fails to format over-length line containing walrus operator (works on master)

Created on 7 Dec 2019  Â·  10Comments  Â·  Source: psf/black

Describe the bug
As per title - lines longer than 88 containing a walrus operator fail to be formatted.

It works on master though (tested in the online version)

To Reproduce Steps to reproduce the behavior:

  1. Take this code
longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname = 5
if x := longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname + longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname:
    print(x)
  1. Run _Black_ on it
  2. See error

Expected behavior A clear and concise description of what you expected to happen.

Environment (please complete the following information):

  • Version: 19.10b0
  • OS and Python version: windows 10, python 3.8.0

Does this bug also happen on master?
It does work on master - tested on online version.
Looks like we just need a new release.

bug unstable formatting

Most helpful comment

Do we have an approximate time of when the release will come up? :)

All 10 comments

I'm also running into an issue with the walrus operator, though it seems to be independent of line length. When running black on a file, it fails on this line

while (foo := my_func(bar)) >= 0:

providing

cannot use --safe with this file; failed to parse source file. AST error message: invalid syntax (, line 12)

By removing the walrus operator from that line, black is successfully able to format the file.

Environment

  • black version 19.10b
  • Python 3.8.0
  • Ubuntu 18.04.3

Does this bug happen on master?
No, this bug does not occur on the master branch. I agree with Martin about the new release.

Thanks for all of the work thus far! :+1:

I managed to reproduce this but only on Windows for some reason. This is an unstable formatting bug:

--- source
+++ first pass
@@ -1,4 +1,7 @@
 longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname = 5
-if x := longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname + longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname:
+if (
+    x := longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname
+    + longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname
+):
     print(x)

--- first pass
+++ second pass
@@ -1,7 +1,7 @@
 longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname = 5
 if (
     x := longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname
     + longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname
-):
+) :
     print(x)

@jcusick13 your issue is different. It seems like Black is not running under Python 3.8. You can either pass in --fast or figure out why it's using a different python version and fix that.

Sounds good. The fast flag has been working for now. You think the issue is
that black is reading a different Python version than the 3.8? I'll dig
into it and report back if I can find anything out.

On Sun, Dec 8, 2019, 14:16 Zsolt Dollenstein notifications@github.com
wrote:

I managed to reproduce this but only on Windows for some reason. This is
an unstable formatting bug:

--- source
+++ first pass
@@ -1,4 +1,7 @@
longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname = 5
-if x := longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname + longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname:
+if (

  • x := longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname

    • longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname

      +):

      print(x)

--- first pass
+++ second pass
@@ -1,7 +1,7 @@
longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname = 5
if (
x := longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname
+ longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname
-):
+) :
print(x)

@jcusick13 https://github.com/jcusick13 your issue is different. It
seems like Black is not running under Python 3.8. You can either pass in
--fast or figure out why it's using a different python version and fix
that.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/psf/black/issues/1194?email_source=notifications&email_token=AFCEGNZKJSPO7DLJQZRREMDQXVBZZA5CNFSM4JXNR7D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGHG5II#issuecomment-562982561,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFCEGNYJ2PHAHR6UZEK43MLQXVBZZANCNFSM4JXNR7DQ
.

I'm also running into this issue. +1 to a release :)

Do we have an approximate time of when the release will come up? :)

Is there a reason why this was not included in 20.8b{0,1}?

We released what was on master at the time. If it's true that this bug was fixed and then reintroduced somewhere later, it would be helpful if someone could bisect so we know what caused it.

This issue was reported on 2019-12-07. Here are the commits from that time:

$ git log --after="2019-12-01" --before="2019-12-10"
commit ac10ca8e60594a6bdf57ff3b078eccb3192d7878
Author: Francisco <[email protected]>
Date:   Sun Dec 8 18:13:50 2019 +0000

    Add Thonny-black-code-format plugin (#1195)

commit b69bce860ccb123b7a6de707496c0b1361bd7b80
Author: Cooper Lees <snip>
Date:   Wed Dec 4 00:33:25 2019 -0800

    Add GitHub Actions badge to README.md (#1134)

But it's failing for me with b69bce860ccb123b7a6de707496c0b1361bd7b80 on macOS:

$ python --version
Python 3.8.5
$ black --version
black, version 19.10b1.dev12+gb69bce8
$ cat 1194.py
longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname = 5
if x := longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname + longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname:
    print(x)
$ black 1194.py --check
error: cannot format 1194.py: INTERNAL ERROR: Black produced different code on the second pass of the formatter.  Please report a bug on https://github.com/psf/black/issues.  This diff might be helpful: /var/folders/kt/j77sf4_n6fnbx6pg199rbx700000gn/T/blk_sxttiv9d.log
Oh no! 💥 💔 💥
1 file would fail to reformat.
$ cat /var/folders/kt/j77sf4_n6fnbx6pg199rbx700000gn/T/blk_sxttiv9d.log
--- source
+++ first pass
@@ -1,4 +1,7 @@
 longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname = 5
-if x := longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname + longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname:
+if (
+    x := longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname
+    + longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname
+):
     print(x)

--- first pass
+++ second pass
@@ -1,7 +1,7 @@
 longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname = 5
 if (
     x := longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname
     + longnamelongnamelongnamelongnamelongnamelongnamelongnamelongname
-):
+) :
     print(x)

Thanks @hugovk for the information. I wrote a little script that went through each commit (between December 01, 2019 to now) to see if this bug was ever fixed and then reintroduced. From my analysis, I do not think that happened. I think the OP said it was fixed on master because the Black playground runs with --fast and therefore it would never error since the unstable formatting and invalid formatting checks are disabled.

Regardless, this bug is fixed on master due to commit 1d2d7264ec7c448744b771910cc972da03b1cb80 so I will close this issue now.

Thanks @hugovk and @ichard26!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Curly-Mo picture Curly-Mo  Â·  3Comments

bhearsum picture bhearsum  Â·  3Comments

brettcannon picture brettcannon  Â·  3Comments

madig picture madig  Â·  3Comments

quodlibetor picture quodlibetor  Â·  3Comments