Black: INTERNAL ERROR: Black produced code that is not equivalent to the source.

Created on 4 Apr 2018  路  4Comments  路  Source: psf/black

Operating system: Arch Linux
Python version: Python 3.6.4
Black version: black, version 18.4a0
Does also happen on master: Not tested when I started to write this issue but it's confusing when blacking code from different branches :joy_cat: :+1:

Hello @ambv and thanks for this :+1: I was using it for replacement of autopep8 in private project and I feel like it was time to test it in some of my Open Source projects.

So as black told me to report a bug so kindly:

error: cannot format PyFunceble.py: INTERNAL ERROR: Black produced code that is not equivalent to the source. Please report a bug on https://github.com/ambv/black/issues. This diff might be helpful: /tmp/blk_z44me8pc.log

Here am I.

Here's the diff out of virtualenv:

--- src
+++ dst
@@ -38877,11 +38877,11 @@
                       s=
                         'Expired:(.*)',  # str
                     )  # /Str
                     Str(
                       s=
-                        "Date d\\'expiration:(.*)",  # str
+                        "Date d'expiration:(.*)",  # str
                     )  # /Str
                 )  # /List
             )  # /Assign
             If(
               body=

and the diff into virtualenv:

--- src
+++ dst
@@ -38877,11 +38877,11 @@
                       s=
                         'Expired:(.*)',  # str
                     )  # /Str
                     Str(
                       s=
-                        "Date d\\'expiration:(.*)",  # str
+                        "Date d'expiration:(.*)",  # str
                     )  # /Str
                 )  # /List
             )  # /Assign
             If(
               body=

The affected code was PyFunceble for the following line:

r'Date d\'expiration:(.*)']

Thanks again :1st_place_medal:

Have a nice day/night.

Most helpful comment

This is a bug in string prefix standardization (cc @zsol). We'll fix it.

As a workaround for now, @funilrys, change r'Date d\'expiration:(.*)' in your code to r"Date d'expiration:(.*)". Those are equivalent in your use case.

All 4 comments

This is a bug in string prefix standardization (cc @zsol). We'll fix it.

As a workaround for now, @funilrys, change r'Date d\'expiration:(.*)' in your code to r"Date d'expiration:(.*)". Those are equivalent in your use case.

But wait, those two strings are always going to be equivalent. Is this actually a bug in equivalence detection? Looks like the source string is parsed incorrectly, there's no \ character in that string. Nevermind I realized this is a raw string :)

@zsol, no, they are not always equivalent. They are only equivalent because as a regular expression, the built-in re library interprets 0x5C 0x27 (backslash apostrophe) as just 0x27 (apostrophe). For a different library the content is just different:

>>> len(r'Date d\'expiration:(.*)')
23
>>> len(r"Date d'expiration:(.*)")
22

Oh, and there totally is a backslash in the original string. That's a quirk of raw strings when escaping the same quote as used in the outer string:

>>> r'Date d\'expiration:(.*)'
"Date d\\'expiration:(.*)"
Was this page helpful?
0 / 5 - 0 ratings