Je ne sais pas pourquoi; mais depuis python 3.8 a été publié; je ne peux pas exécuter la console pycharm et elle est toujours dans l'état "étant connecté".
Je n'ai eu aucun problème avec python 3.7; puisque la console est ouverte immédiatement.
Ici, vous pouvez voir que j'ai essayé plusieurs fois d'exécuter la console mais je sais, même si j'attends un jour; Il ne se connecte pas à la console; mais quand je change l'interpréteur de python3.8 en python3.7, les nouvelles consoles que j'ouvre sont toutes configurées en une seconde.
L'erreur:
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 photo:
spécifications pycharm: version professionnelle pycharm 2019.1.
Cela fonctionne très bien sur PyCharm (Community) 2019..
PyCharm navires [PyPI]: thriftpy (pour la version actuelle, c'est un modifié v0.3.8 ), car il en a besoin pour différentes fonctionnalités (y compris la Python Console ).
Python 3.8 est venu avec un ensemble de modifications (un exemple est [Python]: PEP 570 - Python Paramètres positionnels uniquement ) nécessitant des changements dans bon nombre desrd-party) pour qu'ils fonctionnent (pour certains, il y a toujours WiP ).
Apparemment, ThriftPy est l'un de ces packages qui nécessitent des modifications. Cependant, il n'a pas été maintenu depuis 2016, donc JetBrains conserve (une copie/fork?) Dans leur référentiel.
Quoi qu'il en soit, le problème auquel vous êtes confronté a été résolu par [GitHub]: JetBrains/intellij-community - PY-36069 Python prise en charge de la console pour Python 3.8 .
Malheureusement, je n'ai pas pu trouver le problème sur JetBrains.YouTrack , donc je n'ai pas d'informations supplémentaires à ce sujet (comme quand il a été corrigé, et bientôt).
Ce que je peux vous dire (également mentionné au début), c'est que il a été corrigé (fonctionne) dans PyCharm (Community) 2019.3 , donc si vous mettez-le à niveau, vous ne devriez plus avoir ce problème.
Une solution de contournement (si la mise à niveau n'est pas une option) serait d'appliquer le correctif (dans l'url de validation [~ # ~] [~ # ~] ) à votre (local) _ compat.py fichier. Cochez [SO]: exécuter/déboguer les tests unitaires d'une application Django dans le menu contextuel du clic droit de la souris dans PyCharm Community Edition? (@ Réponse de CristiFati) (Patching utrunner section) pour savoir comment appliquer des correctifs (sur Win ).
Petite mention: l'application du patch inversé à mon fichier local a rendu le problème visible.