pycharm does not connect to console with python3.8

Question

I dont know why; but since python 3.8 has been released; I cant run pycharm console and it is always in the "being connected" status.

I have had no problem with python 3.7; since the console is opened immediately.

Here you can see that I have tried several times to run the console but I know, even if I wait a day; It does not connect to console; but when I change the interpreter from python3.8 to python3.7, The new consoles I open are all set up within a second.

The Error:

C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\pydev\_pydevd_bundle\pydevd_resolver.py:138: SyntaxWarning: "is not" with a literal. Did you mean "!="?
  if found.get(name) is not 1:
Traceback (most recent call last):
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\pydev\pydevconsole.py", line 33, in <module>
    from _pydev_bundle.pydev_console_utils import BaseInterpreterInterface
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\pydev\_pydev_bundle\pydev_console_utils.py", line 11, in <module>
    from _pydevd_bundle import pydevd_thrift
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\pydev\_pydevd_bundle\pydevd_thrift.py", line 17, in <module>
    from pydev_console.protocol import DebugValue, GetArrayResponse, ArrayData, ArrayHeaders, ColHeader, RowHeader, \
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\pydev\pydev_console\protocol.py", line 6, in <module>
    _console_thrift = _shaded_thriftpy.load(os.path.join(os.path.dirname(os.path.realpath(__file__)), "console.thrift"),
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\third_party\thriftpy\_shaded_thriftpy\parser\__init__.py", line 29, in load
    thrift = parse(path, module_name, include_dirs=include_dirs,
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\third_party\thriftpy\_shaded_thriftpy\parser\parser.py", line 502, in parse
    parser.parse(data)
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\third_party\thriftpy\_shaded_ply\yacc.py", line 331, in parse
    return self.parseopt_notrack(input, lexer, debug, tracking, tokenfunc)
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\third_party\thriftpy\_shaded_ply\yacc.py", line 1106, in parseopt_notrack
    p.callable(pslice)
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\third_party\thriftpy\_shaded_thriftpy\parser\parser.py", line 212, in p_struct
    val = _fill_in_struct(p[1], p[3])
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\third_party\thriftpy\_shaded_thriftpy\parser\parser.py", line 765, in _fill_in_struct
    gen_init(cls, thrift_spec, default_spec)
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\third_party\thriftpy\_shaded_thriftpy\thrift.py", line 103, in gen_init
    cls.__init__ = init_func_generator(default_spec)
  File "C:\Program Files\JetBrains\PyCharm 2019.1.3\helpers\third_party\thriftpy\_shaded_thriftpy\_compat.py", line 102, in init_func_generator
    new_code = types.CodeType(len(varnames),
TypeError: an integer is required (got type bytes)

The Photo:

pycharm specs: pycharm professional version 2019.1.3

Answer 1

It works fine on PyCharm (Community) 2019.3.

PyCharm ships [PyPI]: thriftpy (for current version, it's a modified v0.3.8), as it needs it for different features (including the Python Console).

Python 3.8 came with a set of changes (one example is [Python]: PEP 570 -- Python Positional-Only Parameters) requiring changes in many of the existing (3^rd-party) packages in order for them to work (for some of them, there's still WiP).

Apparently, ThriftPy is one of those packages that require changes. However it hasn't been maintained since 2016, so JetBrains keeps (a copy / fork ?) in their repository.

Anyway, the problem you're facing, was fixed by [GitHub]: JetBrains/intellij-community - PY-36069 Python console support for Python 3.8.
Unfortunately, I couldn't find the issue on JetBrains.YouTrack, so I don't have any additional info about it (like when it was fixed, and so on).

What I can tell you (also mentioned at the beginning), is that it was fixed (works) in PyCharm (Community) 2019.3, so if you upgrade it, you should no longer have this problem.

A workaround (if upgrading is not an option) would be to apply the patch (in the commit URL) to your (local) _compat.py file. Check [SO]: Run / Debug a Django application's UnitTests from the mouse right click context menu in PyCharm Community Edition? (@CristiFati's answer) (Patching utrunner section) for how to apply patches (on Win).
Small mention: applying the reversed patch to my local file, made the problem visible.