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:
(source: techpowerup.org)
pycharm specs: pycharm professional version 2019.1.3
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 (3rd-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.
Delete your code program and reload it from git or other svn, it would be ok for Pycharm 2021.2.3 Professional Edition.
Related
I'm running Python 3.10.2288.0 (x64) on a Windows 10 OS.
I use IDLE as interpreter.
So far, I have been running IDLE (in and out venv) by:
C:path\to\venv venv\Scripts\Activate
(venv) C:path\to\venv python -m idlelib.idle
All of a sudden, this command didn't work anymore.
The following error appeared:
Traceback (most recent call last):
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.10_3.10.2288.0_x64__qbz5n2kfra8p0\lib\runpy.py", line 196, in _run_module_as_main
return _run_code(code, main_globals, None,
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.10_3.10.2288.0_x64__qbz5n2kfra8p0\lib\runpy.py", line 86, in _run_code
exec(code, run_globals)
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.10_3.10.2288.0_x64__qbz5n2kfra8p0\lib\idlelib\idle.py", line 13, in <module>
from idlelib.pyshell import main # This is subject to change
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.10_3.10.2288.0_x64__qbz5n2kfra8p0\lib\idlelib\pyshell.py", line 53, in <module>
from idlelib import debugger
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.10_3.10.2288.0_x64__qbz5n2kfra8p0\lib\idlelib\debugger.py", line 7, in <module>
from idlelib import macosx
File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.10_3.10.2288.0_x64__qbz5n2kfra8p0\lib\idlelib\macosx.py", line 7, in <module>
from test.support import requires, ResourceDenied
ModuleNotFoundError: No module named 'test'
I tried to reinstall Python, but nothing changed.
The same error appears when running command outside the venv.
It seems that everything is up-to-date.
What do you suggest?
Thanks,
idromv
This is the result of a buggy fix to a bug that is triggered when Python is installed without the test module. The bug appeared in 3.10.8 and 3.12.0a1, released a week ago, and at least in Microsoft Store Python 3.10.2288.0.
Omitting the test module seem to not currently be an option on Mac, so this should not be a problem there.
One fix anywhere is to edit /Lib/idlelib/macosx.py: delete line 7, from test.support import requires, ResourceDenied, and replace line 23, requires('gui') with pass. This may require admin privileges.
On Windows, rerun the python.org installer, chose Modify, and check the box to install the test suite.
For the Windows store Python, including the test suite may not be an option. One can, as mentioned in the comments, instead get the python.org installer and install with the test suite.
I don't know what the situation is for *nix.
I have faced error while opening the Thonny Ide.
ERROR: Internal error
Traceback (most recent call last):
File "C:\Program Files (x86)\Thonny\lib\tkinter\__init__.py", line 1705, in __call__
return self.func(*args)
File "C:\Program Files (x86)\Thonny\lib\site-packages\thonny\running.py", line 356, in cmd_stop_restart
self.restart_backend(True)
File "C:\Program Files (x86)\Thonny\lib\site-packages\thonny\running.py", line 458, in restart_backend
self._proxy = backend_class(clean)
File "C:\Program Files (x86)\Thonny\lib\site-packages\thonny\running.py", line 1036, in __init__
CPythonProxy.__init__(self, executable)
File "C:\Program Files (x86)\Thonny\lib\site-packages\thonny\running.py", line 624, in __init__
self._start_new_process()
File "C:\Program Files (x86)\Thonny\lib\site-packages\thonny\running.py", line 764, in _start_new_process
debug("Starting the backend: %s %s", cmd_line, get_workbench().get_cwd())
File "C:\Program Files (x86)\Thonny\lib\site-packages\thonny\workbench.py", line 1252, in get_cwd
return normpath_with_actual_case(os.path.expanduser("~"))
File "C:\Program Files (x86)\Thonny\lib\site-packages\thonny\common.py", line 212, in normpath_with_actual_case
assert os.path.isabs(name)
AssertionError
OS: Windows 7 64-bit
Python: Python 3.7(94bit)
Thonny:3.1.2
Open %APPDATA%\Thonny\configuration.ini (or wherever your IDE config is)
Scroll down to [run] section and check parameter working_directory.
Make sure something meaningful is set there, e.g. C:\ should do the trick (no double backslahes, quotes, etc..).
I had the same issue. For some reason only word lib was there. Modifying this parameter to a proper filesystem path fixed it in my case.
Something has corrupted the current instance of your Thonny installation at the backend.
You will first need to completely uninstall Thonny and then remove any imprints of Thonny from your computer's registry.
Then reinstall Thonny and open Thonny IDE.
Hope this helps.
I also faced this issue, for me it was due to Antivirus, just disabling Auto Containment fixed the issue, Hope this helps.
I am running a Python client using PyCharm. If I just run it, PyCharm simply calls:
C:\Python27\python.exe E:/faf/client/src
and everything is fine.
These are my settings:
If I want to debug it, PyCharm calls:
C:\Python27\python.exe "C:\Program Files (x86)\JetBrains\PyCharm Community Edition 5.0.2\helpers\pydev\pydevd.py" --multiproc --qt-support --client 127.0.0.1 --port 52948 --file E:/faf/client/src
and the result is that the modules which are in fact there cannot be included
pydev debugger: process 5092 is connecting
Connected to pydev debugger (build 143.1184)
Traceback (most recent call last):
File "C:\Program Files (x86)\JetBrains\PyCharm Community Edition 5.0.2\helpers\pydev\pydevd.py", line 2407, in <module>
globals = debugger.run(setup['file'], None, None, is_module)
File "C:\Program Files (x86)\JetBrains\PyCharm Community Edition 5.0.2\helpers\pydev\pydevd.py", line 1798, in run
launch(file, globals, locals) # execute the script
File "E:/faf/client/src\__main__.py", line 29, in <module>
import config
ImportError: No module named config
What do I have to do to be able to debug this thing?
I had to click on the src directory and add it as source folder (Mark Directory As -> Source Root). No apparent thing changed like e.g. the way the python command got called.
So if you have a similar looking problem try to do the same.
I resolved this issue for myself by adding an init.py in the folder of the module I was trying to import.
I am having problens debugging my code. When I use OpenCV by importing cv2 I get the following output:
pydev debugger: process 8272 is connecting
Connected to pydev debugger (build 141.1899)
Traceback (most recent call last):
File "C:\Program Files (x86)\JetBrains\PyCharm Community Edition 4.5.3\helpers\pydev\pydevd.py", line 2358, in <module>
globals = debugger.run(setup['file'], None, None, is_module)
File "C:\Program Files (x86)\JetBrains\PyCharm Community Edition 4.5.3\helpers\pydev\pydevd.py", line 1778, in run
pydev_imports.execfile(file, globals, locals) # execute the script
File "C:/work/210 Python/6 imagingSource/test.py", line 3, in <module>
import cv2
File "C:\Program Files (x86)\JetBrains\PyCharm Community Edition 4.5.3\helpers\pydev\pydev_monkey_qt.py", line 71, in patched_import
return original_import(name, *args, **kwargs)
ImportError: DLL load failed: Die angegebene Prozedur wurde nicht gefunden.
So some DLL can not be loaded. I do not get the error when I normally run the file.
I checked the run and debug environments with the os package. They are almost the same, differing only in some additional entries for the pydev debug environment. I think I also checked whether or not a 64bit interpreter is being used by executing sys.maxsize in both environments. They return the same values so I guess they are both the same - 64bit.
So I am without a clue what could be the cause of this issue. Does anyone have an idea?
Thanks in advance!
I don't know what changed, but suddenly none of my Python App Engine projects will start on my PC. They start on my MacBook just fine, so there's something about the installation on my PC that's messed up. I've tried going back to 1.8.8, but that doesn't work. I've also tried using a fresh Python installation, but that didn't work. I've even tried using port 8080 (I usually use port 80, as I run the app launcher as admin).
This is what shows up in the error log when I click start on one of my projects:
2014-02-05 10:42:24 Running command: "['c:\\users\\jonathan\\appdata\\local\\enthought\\canopy\\user\\scripts\\pythonw.exe', 'C:\\Program Files (x86)\\Google\\google_appengine\\dev_appserver.py', '--skip_sdk_update_check=yes', '--port=80', '--admin_port=8000', 'C:\\Users\\jonathan\\My Repositories\\my-project']"
Traceback (most recent call last):
File "C:\Program Files (x86)\Google\google_appengine\dev_appserver.py", line 197, in <module>
_run_file(__file__, globals())
File "C:\Program Files (x86)\Google\google_appengine\dev_appserver.py", line 193, in _run_file
execfile(script_path, globals_)
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\tools\devappserver2\devappserver2.py", line 32, in <module>
from google.appengine.tools.devappserver2.admin import admin_server
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\tools\devappserver2\admin\admin_server.py", line 29, in <module>
from google.appengine.tools.devappserver2.admin import console
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\tools\devappserver2\admin\console.py", line 22, in <module>
from google.appengine.tools.devappserver2 import module
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\tools\devappserver2\module.py", line 69, in <module>
from google.appengine.tools.devappserver2 import wsgi_server
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\tools\devappserver2\wsgi_server.py", line 31, in <module>
from cherrypy import wsgiserver
File "C:\Program Files (x86)\Google\google_appengine\lib\cherrypy\cherrypy\__init__.py", line 278, in <module>
_pydoc._builtin_resolve = _pydoc.resolve
AttributeError: 'module' object has no attribute 'resolve'
2014-02-05 10:42:32 (Process exited with code 1)
Also, I'm using Windows 7 x64. My original installation of Python is from Enthought x64, but I did try using the basic x64 Python as well. As mentioned, I downgraded from 1.8.9 to 1.8.8, to no avail.
From a quick Google search, other users are suggesting it's a bug in pyvenv. Since not very many people are still using CherryPy, and it seems to only manifest itself in whatever CherryPy is doing there, that's probably it.
Bug the gist is that somewhere, only on Windows, you have a pydoc.py file which is being imported instead of the standard library's pydoc file.
So, find the offending pydoc.py file in your import path, and rename it. You can most likely find it by doing something like this:
import pydoc
print pydoc.__file__