You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Invalid Error With Support Of F-Strings Using exec() Function #3695
SyntaxError: Format strings are only supported in Python 3.6 and greater
Running Python version 3.8.3 and Cython version 0.29.20 and using language level set to 3. Have not installed any previous versions of python on my machine. I have programmed thousands of lines in cython and use f-strings constantly. The problem occurred when I defined a class (that incorporated f-strings) in a multi-line string, and created it using the exec() function. This class was pretty complicated so I had thought perhaps I did something wrong so I created a test and got the same error. Which indicated to me that it is a problem with cython itself, not the code I had written.
Test code:
# Same output if you remove the cdef and just use normal python variables
cdef str test_code = """
class Test:
def __init__(self):
var1,var2 = 123,321
self.test = f"{var1}, {var2}"
"""
cdef dict d = {}
exec(test_code, locals(), d)
Test = d['Test']
# Results in the same error described earlier
exec() is not compiled by Cython (it's passed into Python), and Cython does not issue that error message anywhere. In fact, it backports the f-string implementation all the way back to Py2.7.
exec() is not compiled by Cython (it's passed into Python), and Cython does not issue that error message anywhere. In fact, it backports the f-string implementation all the way back to Py2.7.
The code passed into exec is 100% valid python code. Cython should easily be able to use exec() because like you said it's passed into python. There is no issue with this in plain python and the problem is only in cython so yes this is a cython issue.
Looks like a CPython bug to me. At least a documentation bug, but from the docs, a backwards incompatible change doesn't seem intentional. It was introduced in bpo-35975, commit python/cpython@495da29.
This error is issued by CPython when the cf_feature_version in PyCompilerFlags is set to something lower than 6 (i.e. <Py3.6). This field is new in CPython 3.8 and Cython does not set it. According to the documentation, "The field is ignored by default, it is used if and only if PyCF_ONLY_AST flag is set in cf_flags.". Cython does not set that flag, and thus the field should be ignored. But clearly, it isn't.
It's probably easy to fix by initialising that field in Py3.8+ as a work-around.
Activity
scoder commentedon Jun 20, 2020
exec()is not compiled by Cython (it's passed into Python), and Cython does not issue that error message anywhere. In fact, it backports the f-string implementation all the way back to Py2.7.DeathDragon7050 commentedon Jun 20, 2020
The code passed into exec is 100% valid python code. Cython should easily be able to use exec() because like you said it's passed into python. There is no issue with this in plain python and the problem is only in cython so yes this is a cython issue.
scoder commentedon Jun 20, 2020
Looks like a CPython bug to me. At least a documentation bug, but from the docs, a backwards incompatible change doesn't seem intentional. It was introduced in bpo-35975, commit python/cpython@495da29.
This error is issued by CPython when the
cf_feature_versioninPyCompilerFlagsis set to something lower than 6 (i.e. <Py3.6). This field is new in CPython 3.8 and Cython does not set it. According to the documentation, "The field is ignored by default, it is used if and only if PyCF_ONLY_AST flag is set in cf_flags.". Cython does not set that flag, and thus the field should be ignored. But clearly, it isn't.It's probably easy to fix by initialising that field in Py3.8+ as a work-around.
scoder commentedon Jun 20, 2020
I reported the issue in https://bugs.python.org/issue35975#msg371938
DeathDragon7050 commentedon Jun 20, 2020
Thank you for your help.
exec() did not allow recent Python syntax features in Py3.8+ due to h…
update (#1)