pycharm no se conecta a la consola con python3.8

No se porque; pero desde que se lanzó Python 3.8; No puedo ejecutar la consola pycharm y siempre está en el estado "conectado".

No he tenido ningún problema con Python 3.7; ya que la consola se abre de inmediato.

Aquí puede ver que he intentado varias veces ejecutar la consola, pero lo sé, incluso si espero un día; No se conecta a la consola; pero cuando cambio el intérprete de python3.8 a python3.7, las nuevas consolas que abro se configuran en un segundo.

El 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)

La foto:

especificaciones de pycharm: versión profesional de pycharm 2019.1.3

Funciona bien en PyCharm (Comunidad) 2019.3 .

PyCharm incluye [PyPI]: thriftpy (para la versión actual, es una v0.3.8 modificada ), ya que la necesita para diferentes funciones (incluida la consola Python ).

Python 3.8 viene con un conjunto de cambios (un ejemplo es [Python]: PEP 570 - Python posicionales parámetros de sólo ) que requiere cambios en muchos de los existentes (3 ^rd -party) paquetes en orden para que funcionen (por algunos de ellos, todavía hay WiP ).

Aparentemente, ThriftPy es uno de esos paquetes que requieren cambios. Sin embargo, no se ha mantenido desde 2016, por lo que JetBrains mantiene (una copia / fork) en su repositorio.

De todos modos, el problema al que se enfrenta fue solucionado por [GitHub]: JetBrains / intellij-community - PY-36069 Soporte de consola Python para Python 3.8 .
Desafortunadamente, no pude encontrar el problema en JetBrains.YouTrack , por lo que no tengo ninguna información adicional al respecto (como cuando se solucionó, etc.).

Lo que puedo decirte (también mencionado al principio) es que se solucionó (funciona) en PyCharm (Community) 2019.3 , por lo que si lo actualizas, ya no deberías tener este problema.

Una solución alternativa (si la actualización no es una opción) sería aplicar el parche (en la URL de confirmación ) a su archivo (local) _compat.py . Marque [SO]: ¿Ejecutar / depurar las pruebas unitarias de una aplicación Django desde el menú contextual del botón derecho del mouse en PyCharm Community Edition? (@ Respuesta de CristiFati) ( Aplicación de parches utrunner sección) para la forma de aplicar los parches (en Win ).
Pequeña mención: al aplicar el parche invertido a mi archivo local, se hizo visible el problema.