We Keep Coding

Is there a way to load a fxml into jython logic code?

I need to attach a GUI to python application. I've seen tkinter and Qt5, but they make too native GUIs. In fact, using the first one I cannot customize my elements with css, and the second one only support a subset of it. That's why I wonder if I can use a fxml file to create a nice interface.
Then, I followed this link and tried to use jython. In one comment, they said: "you can manually add jfxrt.jar to your module search path if you are using a version of Java where it isn't available." This is my case, but I have no idea about how to do it. I downloaded the jfxrt.jar and I put it in the same python script folder, but the same error occurs when I try jython script.py:
WARNING: Illegal reflective access by jnr.posix.JavaLibCHelper$ReflectiveAccess (file:/usr/share/java/jnr-posix.jar) to method sun.nio.ch.SelChImpl.getFD()
WARNING: Please consider reporting this to the maintainers of jnr.posix.JavaLibCHelper$ReflectiveAccess
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
Traceback (most recent call last):
File "./test.py", line 10, in <module>
from javafx.application import Application
ImportError: No module named javafx
What I executed is the code in the page previously linked. What can I do to solve this import error?

Requiring PsychoPy fails readthedocs build due to memory consumption

I have a project (https://github.com/jfkominsky/PyHab) which is essentially an extension of PsychoPy (http://psychopy.org/). I want to use Sphinx and ReadTheDocs for code documentation. I use the autoclass features from Sphinx for my documentation and have most of it in the code itself, which works great on local builds. On ReadTheDocs, this means that I needed to add a requirements file with psychopy as a requirement. This causes the build to fail in the following way:
/home/docs/checkouts/readthedocs.org/user_builds/pyhab/envs/latest/bin/pip install --exists-action=w --cache-dir /home/docs/checkouts/readthedocs.org/user_builds/pyhab/.cache/pip -rdocs/requirements.txt
Command killed due to excessive memory consumption
I'm very amateur at this. Is there a way to use a setup.py virtual environment to get psychopy to work? Is readthedocs just being too stingy with memory? I've noticed psychopy itself has some issues with RTD builds right now, unsure if that's related...
EDIT: I should add, I was using Cpython2 as my environment in RTD. When I use CPython3 instead I get a different failure:
I tried again with Py3 and got a different error:
ERROR: failed building wxWidgets
Traceback (most recent call last):
File "build.py", line 1321, in cmd_build_wx
wxbuild.main(wxDir(), build_options)
File "/tmp/pip-build-7a1lqn7v/wxPython/buildtools/build_wxwidgets.py", line 374, in main
"Error running configure")
File "/tmp/pip-build-7a1lqn7v/wxPython/buildtools/build_wxwidgets.py", line 85, in exitIfError
raise builder.BuildError(msg)
buildtools.builder.BuildError: Error running configure
Finished command: build_wx (0m10.842s)
Finished command: build (0m10.842s)
Command '"/home/docs/checkouts/readthedocs.org/user_builds/pyhab/envs/latest/bin/python" -u build.py build' failed with exit code 1.

I have devised a solution, at least for CPython2.x. The long and short of it, which RTD needs to advertise MUCH better, is that you can slip a bunch of 'mocks' into conf.py in order to bypass modules you don't want to actually import when compiling your docs. You need mock in your requirements file in 2.7 (presumably unittest.mock in 3.x)
The idea came from here: http://blog.rtwilson.com/how-to-make-your-sphinx-documentation-compile-with-readthedocs-when-youre-using-numpy-and-scipy/
Which connects back to this in the FAQ: http://read-the-docs.readthedocs.io/en/latest/faq.html#i-get-import-errors-on-libraries-that-depend-on-c-modules
I realized that you could create mock modules for literally anything, and if you use MagicMock you can add attributes to them as needed. It took me several tries to get all the right mock modules (mostly because the RTD environment is hard to emulate locally and it would only show you the first module it failed to import in the error message), but eventually, I was able to convince RTD that it had everything it needed without exceeding its memory limits.
This solution is not psychopy-specific. This will work for anything that you have trouble pip installing on RTD.

Python for .Net Error: ImportError: No module named

We are using Python for .Net to call .NET API built using C# from Python script.
We are getting ImportError: No module named - error when an import is done as follows.
Python script:
import sys
sys.path.append(r"C:\myfolderA\myfolderB")
print sys.path
import clr
clr.FindAssembly(r"AA.BB.CC")
clr.AddReference(r"AA.BB.CC")
from AA.BB.CC.Api.DDInterface import DDClient
On the above line I am getting following error
Traceback (most recent call last):
File "C:\myfolderA\myfolderB\testAPI.py", line 7, in <module>
from AA.BB.CC.Api.DDInterface import DDClient
ImportError: No module named AA.BB.CC.Api.DDInterface
There is no other information available to exactly identify the issue.
Dlls from same project built 15 days back works fine.
This project may have gone through few changes in between.
How to exactly identify this issue?
Could this be a dependency issue?
I tried JustDecompile to compare old dlls and new ones, but couldn't find anything unusual.
Your help is deeply appreciated.
Thanks,

With help from python forum I was able to use Microsoft's Fuslogvw.exe (Assembly Binding Log Viewer) and figure out the dependent dll causing the error.
Thanks

Here is a link to my original answer:
https://mail.python.org/pipermail/pythondotnet/2014-December/001626.html
I recommend using Assembly Binding Log Viewer (fuslogvw.exe) for
corresponding .NET framework to see the log files of loading assemblies.
Set Log Location as Custom and in Settings point to your assemblies folder.
The log should show the sequence of DLLs being loaded and any errors.
This worked for me, see here:
Could not load file or assembly or one of its dependencies
Can't locate fuslogvw.exe on my machine

*.pyd file fails to load, but DependancyWalker comes up clean, and ProcMon shows it loaded

I am trying to load a *.pyd with Python, but I receive the well known "Import Error: DLL load failed: the specified procedure can not be found." error.
I have already done the following:
1.) Investigated the *.pyd with Dependency Walker. GPSVC.DLL and IESHIMS.DLL came up as missing, but delay loaded, IEFRAME.DLL aslo came up as missing an export, but was also delay-loaded. It's my understanding that these are not used, and are delay load anyway, so they should not be the problem.
2.) Did an "import foo" on foo.pyd in the python command window, with ProcMon watching. ProcMon shows event "LoadImage" on "foo.pyd" with result SUCCESS.
This seems to imply that the *.pyd file loaded correctly.
So what am I missing. My windows diagnostics are telling me all is well, but python is telling me the thing cannot be loaded (usually due to a missing dll or symbol).
Ideas?
Thanks!

Is the .pyd file for the same version of Python you're using? Loading a .pyd file for the wrong Python version can produce that error message.
Dependency Walker can show you which pythonNN.dll it links to.

If you have a file foo.pyd, for import foo to succeed, there must be an externally accessible function named initfoo. Dependency Walker will show this (typically the ONLY function) if it exists. initfoo needs to be called by Python to initialise the foo module.
Note: I would expect a more explicit error message if this were the problem:
>>> import fubar
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dynamic module does not define init function (initfubar)
>>>
You say that you are "trying to load a *.pyd file". Is that just a strange way of describing import foo or is it something else?
Did you create the pyd? If not, who did? Have you asked them? Is this pyd available on the web so that others could try to load/import it?

Ok here is the answer:
The windows diagnostics (depends, procmon, etc) were showing the DLL (or pyd) loading fine.
Python was showing that it was not loading fine.
I found that the windows tools were referring to a different Python26.dll hiding in my C:\Window\SysWOW64 folder.
This second Python26.dll (found in SysWOW64) has a symbol that is missing in the primary python26.dll (installed by the windows python installer, found in C:\Python26).
This symbol "_PyByteArray_empty_string", was apparently needed by my *.pyd file.
So when loading via windows diagnostics, the SysWOW64 dll was found, and the *.pyd loaded properly. When loading from python, the dll in C:\Python26\ was found, the symbol was missing, and load failed.
So that is WHY the problem manifested. The question now is: Why are there two versions of Python26.dll floating around, one with _PyByteArray_empty_string, and one without?
I'm using Python 2.6.6. Perhaps this symbol is removed in 2.6.6 but present in some older 2.6.x release?

How can I tell python which version of libmysqlclient.so to use?

I'm running a python script on a shared hosting server which until this morning had MySQL version 4. Now it has version 5. My python script can no longer connect to MySQL, as it can't find libmysqlclient_r.so.14:
$ python my_script.py
Traceback (most recent call last):
File "my_script.py", line 6, in ?
import MySQLdb
File "/home/lib/python2.4/site-packages/PIL-1.1.6-py2.4-linux-i686.egg/__init__.py", line 19, in ?
File "build/bdist.linux-i686/egg/_mysql.py", line 7, in ?
File "build/bdist.linux-i686/egg/_mysql.py", line 6, in __bootstrap__
ImportError: libmysqlclient_r.so.14: cannot open shared object file: No such file or directory
There are various other versions of libmysqlclient in /usr/lib:
/usr/lib/libmysqlclient.so.15
/usr/lib/libmysqlclient.so.14
/usr/lib/mysql/libmysqlclient.la
/usr/lib/mysql/libmysqlclient.so
/usr/lib/mysql/libmysqlclient_r.so
/usr/lib/mysql/libmysqlclient_r.a
/usr/lib/mysql/libmysqlclient_r.la
/usr/lib/mysql/libmysqlclient.a
/usr/lib/libmysqlclient.so
/usr/lib/libmysqlclient_r.so
/usr/lib/libmysqlclient_r.so.15
/usr/lib/libmysqlclient_r.so.15.0.0
/usr/lib/libmysqlclient.so.15.0.0
So my question is this: how can I tell python (version 2.4.3) which version of libmysqlclient to use?

You can't tell the dynamic linker which version of a library to use, because the SONAME (full name of the library + interface) is part of the binary.
In your case, you can try to upload libmysqlclient_r.so.14 to the host and set LD_LIBRARY_PATH accordingly, so tell the dynamic linker which directories to search additionally to the system dirs when resolving shared objects.
You can use ldd to see if it LD_LIBRARY_PATH works:
$ ldd $path_to/_mysql.so
...
libmysqlclient_r.so.14 => $path_to_lib/libmysqlclient_r.so.14
...
Otherwise, there will be an error message about unresolved shared objects.
Of course that can only be a temporary fix until you rebuild MySQLdb to use the new libraries.

You will have to recompile python-mysql (aka MySQLdb) to get it to link to the new version of libmysqlclient.
If your host originally set up the environment rather than you compiling it, you'll have to pester them.
/usr/lib/libmysqlclient.so.14
This looks like a remnant of the old libmysqlclient, and should be removed. The _r and .a (static) versions are gone and you don't really want a mixture of libraries still around, it will only risk confusing automake.
Whilst you could make a symbolic link from libmysqlclient_r.so.14 to .15, that'd only work if the new version of the client happened to have the same ABI for the functions you wanted to use as the old - and that's pretty unlikely, as that's the whole point of changing the version number.

One solution is to set your PYTHONPATH environment variable to have some local directory, and copy over (or link, I suppose) the version of the mysql lib you want.