I have a problem with my PyCharm. After I updated Python from 3.3.5 to 3.4, I have an annoying error in PyCharm of the following form:
from multiprocessing import Queue, Process
PyCharm underlines Queue and Process in red and shows an unresolved reference. The code actually runs fine both in the command line and inside PyCharm. Code completion seems to be broken too for these classes.
I am suspecting a problem with PYTHONPATH, but I'm not sure how to solve it.
System details: Mac OS X 10.9.2, Python 3.4 installed through Homebrew, Pycharm 3.1.1
It's not a problem with PYTHONPATH. If we look in multiprocessing\__init__.py, we see the following:
#
# Copy stuff from default context
#
globals().update((name, getattr(context._default_context, name))
for name in context._default_context.__all__)
__all__ = context._default_context.__all__
Notably there is nothing in the file that looks like Queue, Process, etc.
Now what is this context._default_context? If we look in multiprocessing\context.py, we see
class BaseContext(object):
...
def Queue(self, maxsize=0):
'''Returns a queue object'''
from .queues import Queue
return Queue(maxsize, ctx=self.get_context())
So in reality, Queue is never defined in the module itself, but rather through some dynamic code, it gets set correctly at runtime depending on the user's operating system. This is why Pycharm doesn't know that there are Queue and Process classes in the multiprocessing module.
Maybe you can file a bug report and try to get them to selectively run code to figure out these dynamic names or to make an exception here and put some workaround that tells Pycharm that there are in fact Queue/Process classes, but that seems like it would be low on their priority list. So you'll just have to live with it, probably. (In the same boat here)
I'd definitely report an issue with JetBrains if one doesn't already exist, but I would not suggest downgrading Python merely due to your IDE not interpreting an import as expected (the actual interpreter still works).
I have the same issue, simply adding # noinspection PyUnresolvedReferences above the unresolved references silences the compiler 'errors'. Of course I'd love this to be fixed and will remove the # noinspection lines once it is, but it certainly won't stop me from writing code using PyCharm and Python 3.4.
Edit: Looks like someone reported it: http://youtrack.jetbrains.com/issue/PY-12860
Edit: Reportedly fixed in build 138.913
I have had the same issue. If you are using python 3.4.4, please try this:
from queue import Queue
You can read more here: https://docs.python.org/3.4/library/queue.html
Related
I have written a BPF program that I can install using gobpf, i.e. using their bcc tooling. While this works alright from a main package, this breaks as soon as I move it into a package for importing it as a module.
To clarify: It works with all code in package main, but as soon as I rename the package and move the main() to cmd/command.go it stops working with go run complaining that it can't find an included lib (bcc/proto.h). Incidentally, this is the same error as I always got when running gcc on my .c file without any indication I want to use BPF (the part that gobpf did for me, until I moved its invocation to a module...).
I realize this is question very specific and sits in a weird place between Go, CGo, the way C and C++ handle includes, BPF, and bcc, but I am at a loss here.
You can check out my code here https://github.com/bwNetFlow/bpfdump if that helps. It needs bcc installed in addition to go run doing its thing. Basically:
HEAD is the modularized version that does not work (go run cmd/dump.go)
HEAD~ is my initial experiment that does work (go run bpfdump.go) (you'll get an permission error as user, which is fine as it has compiled anyways).
PS: I think it might have to do with this (rather creative?) construction of bcc/proto.h: https://github.com/iovisor/bcc/blob/master/src/cc/exported_files.cc
I just created a Python module from C++ with Boost.Python. It seems to work fine. The only thing which annoys me a bit is when I import it in PyCharm, it underlines the name of the module with red color. When I run the script, everything works fine.
Sure, I can ignore the unresolved reference, but that is not what I want because I would like the whisperer to work.
My question is: Is it even possible to "teach" PyCharm to whisper function, classes etc. of my module? And if so, how?
Initially, I wanted to install the updated MinGW packages using the MinGW-get GUI, but it crashes when I choose "Mark All Upgrades" from the 'Installation' drop-down menu (whether I update the catalogue or not).
Now, I want to figure out why guimain.exe is crashing.
How can I diagnose and debug this persistent problem? I am vaguely familiar with GDB, but I've never used it. I am not committed to using the Visual Studio debugger.
I assume I need to use some ancillary binaries or debug libraries in the latest MinGW installer branch here: https://sourceforge.net/projects/mingw/files/Installer/mingw-get/mingw-get-0.6.2-beta-20131004-1/
Can anyone please guide me? Any assistance or suggested reading is appreciated.
For those who are experiencing the crash on attempting to upgrade packages.. try running it in recursive mode..
mingw-get upgrade --recursive
that appeared to force an upgrade for me..
I happen to have the same issue. The GDB way to debug this:
gdb mingw-get.exe
r upgrade (run with argument upgrade)
GDB will automatically stop at a SIGSEGV (Segmentation fault) signal, that's what happens for me.
bt (get a backtrace)
For me this resulted in a huge backtrace, filled with calls to:
#5013 0x6f9cdda4 in mingw-get-0!_ZN14pkgXmlDocument19ResolveDependenciesEP10pkgXmlNodeP13pkgActionItem () from c:\MinGW\libexec\mingw-get\mingw-get-0.dll
It looks like a recursion problem that quickly filled up the call stack.
Note that function name is mangled, and we don't know the line number. This is the best you can do without debugging symbols. If you have the debugging symbols, GDBs output becomes more useful. For most Linux-style packages, you can get the debugging symbols in a -dbg package named similiarly to the stripped binary package. However I don't see a debug package for mingw32-mingw-get in the listing.
I downloaded everything described as in pygtk for installation. Everything went fine until when I tried to type "import gtk", it threw an ImportError as follows:
from gtk import _gtk
ImportError: DLL load failed: ...(something unreadable)
Then I re-install the pygtk-2.22.0 again, the same problem existed. So what to do please? Thanks in advance!
The error you describe is usually caused by the python bindings (pygtk/pygobject/pycairo) being unable to load a dll it needs to function properly. Most of those errors are either caused by:
the GTK+ runtime not being on your PATH environment variable. This has long been
the advice on how to get pygtk working on Windows. Please don't change your user
or system PATH environment variable, it is no longer needed with the all-in-one
installer.
multiple GTK+ runtime versions are on your PATH environment variable and the first
(leftmost) one is not compatible with the pygtk/pygobject/pycairo versions you use.
This is why adding the GTK+ runtime to your PATH environment variable is a bad idea:
it is easy to mix up versions (sometimes GTK+ related installers add their bin
directory to PATH on installation which contains an older or incomplete runtime).
a rare case where some software package installed libintl.dll and iconv.dll into
%WINDIR%\system or %WINDIR%\sytem32
The most straightforward way to avoid the dll hell described above is to use the
PyGTK All-in-one installer (http://download.gnome.org/binaries/win32/pygtk/2.22/).
It contains both the Python bindings, the GTK+ runtime and even Glade and does
no longer require you to change the PATH environment variable.
Small warning: if you decide to use the all-in-one installer, you'll have to uninstall
the separate pygtk/pygobject/pycairo packages you've used before (or you'll be in
a world of trouble...)
read the source code, perhaps there is a need for a specific version of pygtk
edit the source code to work with your pygtk version
I had this issue as well. You didn't mention for sure in your answer, so I'll suggest the obvious (well...the obvious to people that have used it a while, perhaps). Did you use the following three lines of code to import? You have to use these, in order, to import PyGTK.
I'm assuming your version here is 2.24 like mine. If not, change it to the version you have.
import pygtk
pygtk.require('2.24')
import gtk
That should suffice in importing gtk.
Problem
As others have noted, don't put gtk in the path. I know, its tempting, and it works for XYZ, but it (to say the least) gets confusing. Dependency hell is bad enough on a platform like Linux which tries to make it easy for you.
For clarification, what the PyGTK All In One does for you is to install (what appears to be) a full gtk+ runtime directly in your python packages folder, so e.g. in C:\Python\Lib\site-packages\gtk-2.0\runtime
Solution
NOTE: %YOURPYTHONPATH% is an EXAMPLE variable which contains the path of your Python installation (e.g. C:\Python, or C:\Python27, or whatever it actually is). I suggest setting %PYTHON_DIR% or %PYTHON_PATH% if you want to use a variable to do this, as more programs are likely to use this.
To get your XYZ program requiring GTK to work, add %YOURPYTHONPATH%\Lib\site-packages\gtk-2.0\runtime\bin to the PATH when running your program; the correct versions of the DLLs it needs to link against are in that folder. All other GTK+ runtimes I had installed (GTK+/GTK2-Runetime) gave me errors.
Again; Do not attempt to set a user or system level variable (don't open up the dialog pictured below) as this will likely cause problems for you later unless you VERY sure you know what you are doing. If you are reading this, you most likely don't know as much as you think you do. Instead, alter the path in a cmd prompt, or use a batch/script file to set it up for you.
After you install the pygtk.org package, install each of these in the following order:
pycairo-1.8.6.win32-py2.6.exe
pygobject-2.20.0.win32-py2.6.exe
pygtk-2.16.0+glade.win32-py2.6.exe
gtk+-bundle_2.16.6-20100912_win32.zip
For more information:
http://freetstar.com/windows7-pygtk-gtk/
I got the secusses according the link on my PC.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I already attempted using py2exe (not compatible with ipy) and PYC (out of date). Can anyone point me in the direction of a good compiler?
You can use pyc.py, the Python Command-Line Compiler, which is included in IronPython since version 2.6 to compile a Python script to an executable. You find it at %IRONPYTONINSTALLDIR%\Tools\Scripts\pyc.py on your hard disk.
Example
Let's assume you have a simple script test.py that just prints out something to console. You can turn this into an executable with the following command-line (assuming that the IronPython directory is the current directory and that test.py is in there, too):
ipy.exe Tools\Scripts\pyc.py /main:test.py /target:exe
Note: If you are using forms and don't want a console window to open, you want to use /target:winexe instead of /target:exe.
The result will be two files, test.dll and test.exe. test.dll will contain your actual script code, while test.exe is just a launcher for test.dll. You can distribute this EXE and DLL to other computers which do not have IronPython installed if you include the files
IronPython.dll,
Microsoft.Dynamic.dll,
Microsoft.Scripting.Core.dll,
Microsoft.Scripting.Debugging.dll,
Microsoft.Scripting.dll,
Microsoft.Scripting.ExtensionAttribute.dll and
IronPython.Modules.dll (sometimes needed).
Also see the blog entry IronPython - how to compile exe.
This is a long standing question about which there is very little information on the internet. The only known solution I can find is at http://community.sharpdevelop.net/blogs/mattward/archive/2010/03/16/CompilingPythonPackagesWithIronPython.aspx which uses SharpDevelop. However, this solution is impractical because any semi-complex python project will do a LOT of module imports, and the SharpDevelop solution requires you to create a project per import. I started at it and gave up after about thirty new projects, better to write an automated solution!
So here's my solution, and I'll warn you right now it's not being released as a proper project for good reason:
#!/usr/bin/env python
# CompileToStandalone, a Python to .NET ILR compiler which produces standalone binaries
# (C) 2012 Niall Douglas http://www.nedproductions.biz/
# Created: March 2012
import modulefinder, sys, os, subprocess, _winreg
if len(sys.argv)<2:
print("Usage: CompileEverythingToILR.py <source py> [-outdir=<dest dir>]")
sys.exit(0)
if sys.platform=="cli":
print("ERROR: IronPython's ModuleFinder currently doesn't work, so run me under CPython please")
sys.exit(1)
sourcepath=sys.argv[1]
destpath=sys.argv[2][8:] if len(sys.argv)==3 else os.path.dirname(sys.argv[0])
ironpythonpath=None
try:
try:
keyh=_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "SOFTWARE\\IronPython\\2.7\\InstallPath")
ironpythonpath=_winreg.QueryValue(keyh, None)
except Exception as e:
try:
keyh=_winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, "SOFTWARE\\Wow6432Node\\IronPython\\2.7\\InstallPath")
ironpythonpath=_winreg.QueryValue(keyh, "")
except Exception as e:
pass
finally:
if ironpythonpath is not None:
_winreg.CloseKey(keyh)
print("IronPython found at "+ironpythonpath)
else:
raise Exception("Cannot find IronPython in the registry")
# What we do now is to load the python source but against the customised IronPython runtime
# library which has been hacked to work with IronPython. This spits out the right set of
# modules mostly, but we include the main python's site-packages in order to resolve any
# third party packages
print("Scanning '"+sourcepath+"' for dependencies and outputting into '"+destpath+"' ...")
searchpaths=[".", ironpythonpath+os.sep+"Lib"]
searchpaths+=[x for x in sys.path if 'site-packages' in x]
finder=modulefinder.ModuleFinder(searchpaths)
finder.run_script(sourcepath)
print(finder.report())
modules=[]
badmodules=finder.badmodules.keys()
for name, mod in finder.modules.iteritems():
path=mod.__file__
# Ignore internal modules
if path is None: continue
# Ignore DLL internal modules
#if '\\DLLs\\' in path: continue
# Watch out for C modules
if os.path.splitext(path)[1]=='.pyd':
print("WARNING: I don't support handling C modules at '"+path+"'")
badmodules.append(name)
continue
modules.append((name, os.path.abspath(path)))
modules.sort()
print("Modules not imported due to not found, error or being a C module:")
print("\n".join(badmodules))
raw_input("\nPress Return if you are happy with these missing modules ...")
with open(destpath+os.sep+"files.txt", "w") as oh:
oh.writelines([x[1]+'\n' for x in modules])
cmd='ipy64 '+destpath+os.sep+'pyc.py /main:"'+os.path.abspath(sourcepath)+'" /out:'+os.path.splitext(os.path.basename(sourcepath))[0]+' /target:exe /standalone /platform:x86 /files:'+destpath+os.sep+'files.txt'
print(cmd)
cwd=os.getcwd()
try:
os.chdir(destpath)
retcode=subprocess.call(cmd, shell=True)
finally:
os.chdir(cwd)
sys.exit(retcode)
This was written against IronPython v2.7.2 RC1 using its new standalone binary feature, and indeed it does work. You get a standalone .exe file which is totally self-contained - it needs nothing else installed. The script works by parsing the imports for the supplied script and sending the entire lot to pyc.py. That's the good news.
The bad news is as follows:
IronPython v2.7.2 RC1's ModuleFinder doesn't appear to work, so the above script needs to be run using CPython. It then uses CPython's ModuleFinder but against IronPython's customised runtime library. Yeah, I'm amazed it works as well ...
The binaries output start at about 8Mb. A simple unit test weighed in at 16Mb. There's a lot of stuff that doesn't need to be in there e.g. it throws it Wpf support and a bit more, but still they aren't small.
Load times are much slower than non-standalone. Think about forty seconds for a standalone unit test on a fast Intel Core 2 versus about three seconds for non-standalone. If compiled just for x86, that drops to ten seconds.
Run time performance is slower than non-standalone by about 40%. If compiled just for x86, performance approximately doubles. This is why I left in the /platform:x86 above.
There is a well known bug in CPython's encodings and codecs support where ModuleFinder doesn't include any codec support at all unless you manually specify it. So, for example, if you are using UTF-8 with codecs.open() then you NEED a "from encodings import utf_8 as some_unique_identifier" to force the dependency.
The above assumes a modified pyc.py which can take a /files parameter as the command line length limit easily gets exceeded. You can modify your own pyc.py trivially, if not I've submitted the enhancement for inclusion into the next IronPython.
So there you go. It works, but the solution still needs a lot more maturing. Best of luck!
Check out the IronPython Samples Page
About half way down the page:
Pyc - Python Command-Line Compiler
This sample shows developers how to create .NET executables directly out of IronPython scripts. The readme.htm in the download will get you started.
IronPython’s Hosting APIs can be used to compile Python scripts into DLLs, console executables, or Windows executables. The pyc.py script included in this tutorial leverages these hosting APIs and can be used to compile other Python scripts. It provides a variety of flags such as the ability to specify the target platform of the .NET assembly (e.g., x64).
While the assemblies produced by the IronPython Hosting APIs are true .NET assemblies, the dynamic nature of the Python language makes it difficult to use these from other .NET languages. In short, this means that attempting to import Python types into other .NET languages such as C# is not recommended.
Edit: Just noticed that you mentioned PYC was out of date. What makes it so? The IronPython crew seem to still be promoting it, so I would imagine that it's not that far gone.
I had a bit of trouble trying to implement this solution.
This is what I did:
Download pyc from here.
This took me more searching than it should have because it seems that pyc is hard to find (and I think, a little out of date)
I extracted the pyc folder from the zip file and added it to my IronPython folder in C:\Program Files
Now I tried running this command on the windows console, as instructed by the readme in the pyc download:
ipy.exe pyc.py other_hw.py /main:console_hw.py
It gave me this error:
Traceback (most recent call last):
File "pyc\pyc.py", line 35, in pyc\pyc.py
AttributeError: attribute 'CompilerSink' of 'namespace#' object is read-only
I made the following change to line 35:
Before: class PycSink(Hosting.CompilerSink):
After: class PycSink():
Saving the file proved to be a problem due to permissions, so I copied the contents of pyc.py into a new IDLE window (to create a copy), deleted the existing copy of pyc.py and saved the copy as pyc.py in the same location. This takes care of permissions issues and allows changes.
After making this change, I tried running the this command again:
ipy.exe pyc.py other_hw.py /main:console_hw.py
However, this time, I got the following error:
Traceback (most recent call last):
File "pyc\pyc.py", line 170, in pyc\pyc.py
File "pyc\pyc.py", line 56, in Main
AttributeError: attribute 'ResourceFile' of 'namespace#' object is read-only
At this point, I took stock of the fact that it is now 1 AM and I have a midterm tomorrow, so I undid the changes and shut it down.
Please let me know if you have a solution, or any advancements on mine.
Yes I have found it too difficult to compile an exe so I have switched back to using standard Python. They should give a good tutorial on it on the IronPython site