I cannot debug a Flask application in PyCharm. The application should run on port 5000: app.run(host="10.1.0.17", port=5000, debug=True). The console output is:
C:\Python\python.exe "C:\Program Files (x86)\JetBrains\PyCharm 145.597.11\helpers\pydev\pydevd.py" --multiproc --qt-support --client 127.0.0.1 --port 10498 --file "D:/TGM/SMS/SMS/Back .v2/wsgi.py"
pydev debugger: process 4108 is connecting
Could not connect to 127.0.0.1: 10499
Traceback (most recent call last):
File "C:\Program Files (x86)\JetBrains\PyCharm 145.597.11\helpers\pydev\pydevd.py", line 1523, in <module>
debugger.connect(host, port)
File "C:\Program Files (x86)\JetBrains\PyCharm 145.597.11\helpers\pydev\pydevd.py", line 317, in connect
self.initialize_network(s)
File "C:\Program Files (x86)\JetBrains\PyCharm 145.597.11\helpers\pydev\pydevd.py", line 304, in initialize_network
self.writer = WriterThread(sock)
File "C:\Program Files (x86)\JetBrains\PyCharm 145.597.11\helpers\pydev\_pydevd_bundle\pydevd_comm.py", line 392, in __init__
self.cmdQueue = _queue.Queue()
AttributeError: module 'queue' has no attribute 'Queue'
Process finished with exit code -1
I am using Python 3.5.1. What could be wrong?
The pydev debugger uses the same Pythonpath as the project you are trying to debug.
If you have any modules or packages with names of standard modules or packages, the pydev debugger might load your module instead of the standard module.
You probably have a module called queue in your projects directories, which causes this issue, since the python standard library also includes a module with that name.
try renaming your module, or changing your PYTHONPATH
PyCharm has the option to not include the projects root/source roots in the PYTHONPATH in Run > Edit Configurations. This could fix your problem, although you might need to fix some import statements in your project, if any of your import statements relied on this setting.
Related
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.
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'm having a hard time setting up a flask project on windows. It works like a charm on mac, but on windows 7 I get this:
<module 'ntpath' from 'C:\PYTHON27\LIB\ntpath.pyc'>
ERROR 2015-01-18 17:52:22,927 wsgi.py:263]
Traceback (most recent call last):
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\runtime\wsgi.py", line 240, in Handle
handler = _config_handle.add_wsgi_middleware(self._LoadHandler())
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\runtime\wsgi.py", line 299, in _LoadHandler
handler, path, err = LoadObject(self._handler)
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\runtime\wsgi.py", line 85, in LoadObject
obj = __import__(path[0])
File "C:\Users\Fille\PycharmProjects\Objektia-Marketplace\main.py", line 69, in <module>
from flask_wtf.csrf import CsrfProtect
ImportError: No module named flask_wtf.csrf
INFO 2015-01-18 18:52:22,938 module.py:718] default: "GET /backends HTTP/1.1" 500 -
All tested computers (4 yosemite, 1 win7) run the same version of pycharm (3.4.1) with the same versions of all modules (newest). All modules for the configured interpreter on the mac are also installed on the windows machines interpreter. They are running python 2.7.6 since 2.7.9 doesn't work with app engine yet. Also tried 2.7.2 on windows 7 with the same result.
It seems like windows can't find flask_wtf, but it's installed in the same way as on mac (using tools in pycharm). Any idea on how to fix this?
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__
I'm trying to set up a virtualenv for local development using Google App Engine and django-nonrel. I'm only trying to run the test app provided by django-nonrel for now.
The first time I tried, I got python manage.py runserver to work, but as soon as I tried to fetch a page from localhost:8080, it errored out on me, saying it couldn't find the pdb module:
Traceback (most recent call last):
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\tools\dev_appserver.py", line 2755, in _HandleRequest
self._Dispatch(dispatcher, self.rfile, outfile, env_dict)
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\tools\dev_appserver.py", line 2643, in _Dispatch
base_env_dict=env_dict)
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\tools\dev_appserver.py", line 682, in Dispatch
base_env_dict=base_env_dict)
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\tools\dev_appserver.py", line 1717, in Dispatch
self._module_dict)
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\tools\dev_appserver.py", line 1619, in ExecuteCGI
reset_modules = exec_py27_handler(config, handler_path, cgi_path, hook)
File "C:\Program Files (x86)\Google\google_appengine\google\appengine\tools\dev_appserver.py", line 1425, in ExecutePy27Handler
import pdb
ImportError: No module named pdb
I tried copying modules from my main Python installation, and I also tried creating a new virtualenv which had access to site-packages. Both approaches worked up to a point - python manage.py runserver ended up not being able to find urllib.
On the other hand, python manage.py shell and then e.g. import pdb or import urrlib (or any other standard library, for that matter) work fine. What am I supposed to do?
The solution: don't use virtualenv at all, and put the libraries you're going to need (such as django) in your project directory. You're going to need that to deploy your app to GAE, anyway.