For some reason, I cannot for the life of me figure out why curses won't let me use the A_ITALIC attribute.
All of the other attributes seem to work with no issues, but italic specifically triggers an error message.
I'm running Python 3.10.4, here's some sample code:
import curses
def main(stdscr):
stdscr.addstr(0, 0, "This should be italicized!", curses.A_ITALIC)
stdscr.getch()
if __name__ == '__main__':
curses.wrapper(main)
Python on MacOS could support A_ITALIC if it is built using a recent version of ncurses (since 2013, e.g., ncurses 6.x). The system version of ncurses for MacOS is far too old for that.
The same applies to Python on other platforms, e.g., NetBSD and legacy Unix systems.
With correspondingly recent versions of Python, you can check which version of ncurses using the version or the ncurses_version function. However, even with a recent ncurses version, there's always the possibility of a bug in Python which interferes with providing that feature.
Python's curses wrapper (see source) knows about the feature because its name is compiled-in when Python is built:
/* ncurses extension */
#ifdef A_ITALIC
SetDictInt("A_ITALIC", A_ITALIC);
#endif
Changing the underlying ncurses would not affect that (unless Python is rebuilt).
From the curses documentation:
The exact constants available are system dependent.
I tried it in Python 3.9.12 on macOS, and it didn't work, but it did work using Python 3.10.4 in a Docker container.
Related
I try to use an assembly for .NET framework 4.8 via Pythonnet. I am using version 3.0.1 with Python 3.10. The documentation of Pythonnet is stating:
You must set Runtime.PythonDLL property or PYTHONNET_PYDLL environment variable starting with version 3.0, otherwise you will receive BadPythonDllException (internal, derived from MissingMethodException) upon calling Initialize. Typical values are python38.dll (Windows), libpython3.8.dylib (Mac), libpython3.8.so (most other Unix-like operating systems).
However, the documentation unfortunately is not stating how the property is set and I do not understand how to do this.
When I try:
import clr
from pythonnet import load
load('netfx')
clr.AddReference(r'path\to\my.dll')
unsurprisingly the following error is coming up
Failed to initialize pythonnet: System.InvalidOperationException: This property must be set before runtime is initialized
bei Python.Runtime.Runtime.set_PythonDLL(String value)
bei Python.Runtime.Loader.Initialize(IntPtr data, Int32 size)
bei Python.Runtime.Runtime.set_PythonDLL(String value)
bei Python.Runtime.Loader.Initialize(IntPtr data, Int32 size)
[...]
in load
raise RuntimeError("Failed to initialize Python.Runtime.dll")
RuntimeError: Failed to initialize Python.Runtime.dll
The question now is, where and how the Runtime.PythonDLL property or PYTHONNET_PYDLL environment variable is set
Thanks,
Jens
I believe this is because import clr internally calls pythonnet.load, and in the version of pythonnet you are using this situation does not print any warning.
E.g. the right way is to call load before you call import clr for the first time.
The way I understand your use case is for Embedding .NET in Python however, the way I understand the requirement to "set Runtime.PythonDLL property" is that is for Embedding Python in .NET which was my use case. Anyhow, maybe the following will be useful.
Hidden at the bottom of the main GitHub README.md is a link to the WiKi (and of course the tab at the top of the GitHub repo) where thankfully there is a lot more detailed information and links to useful articles.
The main README.md asserts Runtime.PythonDLL "must be set" yet their example code does not illustrate doing so. Furthermore, the documentation on the official website asserts Python.Runtime.dll must be "referenced" which further confuses things.
In my experience Python.Runtime.dll was automatically referenced when installing the pythonnet NuGet package via Visual Studio. Perhaps Python.Runtime.dll does not automatically get referenced in earlier version or maybe when Python.NET is installed in other ways other than by using NuGet?
To answer your question "how to set Runtime.PythonDLL property?". My understanding is the way that is done is by assigning a string path to that property before the other usual setup:
Runtime.PythonDLL = #"C:\Users\<username>\AppData\Local\Programs\Python\Python310\python38.dll"
In my case, I found this path by using where python on Windows (which in bash, or Get-Command in PowerShell):
C:\>where python
C:\Users\<username>\AppData\Local\Programs\Python\Python310\python.exe
I would like to use the following Python package, which requires ncurses: https://pypi.python.org/pypi/blessings
I have the Windows version of Anaconda Python installed, and designated as my Python distribution.
I have also have a Cygwin installation. When I run python -i within the provided Cygwin terminal, Anaconda Python starts up -- great!
If I then try import blessings, I'll get the following error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "A:\anaconda\lib\site-packages\blessings\__init__.py", line 5, in <module>
import curses
File "A:\anaconda\lib\curses\__init__.py", line 15, in <module>
from _curses import *
ImportError: No module named _curses
Alright, so what's happening is that Anaconda Python is understandably not picking up Cygwin's curses.
Now, does it even make sense to try and somehow make Anaconda aware of ncurses, only within the context of usage in a Cygwin terminal? I suspect it isn't, and that I am missing something conceptually?
You won't be able to use Cygwin Python's curses module with CPython unfortunately. Modules for the two Pythons are incompatible for the following reasons (and more):
Windows Python directly calls the Win32 API (via either the Visual Studio 2008, 2010 or 2015 C-Runtimes) while Cygwin Python links to the Cygwin POSIX API which is layered on top of the Visual Studio 6.0 C-Runtime. Mixing different C-Runtimes in a single process is a very bad idea: http://siomsystems.com/mixing-visual-studio-versions/, never mind further abstracted through a POSIX API.
Regardless of the C-Runtime differences, Cygwin implements the LP64 model while Windows implements the LLP64 model which would make the 64-bit size of long different between each, so some structures could be differently sized. They would likely be anyway due to #ifdefs in the code.
Is there any reason you can't use colorama?
The documentation for blessings suggests that should work.
I just successfully installed PyEphem using pip in a pyenv. However, on import I receive:
ImportError: /python2.7/site-packages/ephem/_libastro.so: undefined symbol: PyUnicodeUCS2_AsUTF8String
In looking around I've seen it mentioned that some modules are built "against Python" in regards to Unicode and suggest recompiling. I'm quite new to Python and Ubuntu 14.04, and although I believe this is the answer to my issue, I do not know what recompiling means or how to do it.
The symbol PyUnicode_AsUTF8String(value) is used once in _libastro.c and is defined on my system in the file:
/usr/include/python2.7/unicodeobject.h
There it can be aliased one of two ways:
#ifndef Py_UNICODE_WIDE
# ...
# define PyUnicode_AsUTF8String PyUnicodeUCS2_AsUTF8String
# ...
#else
# ...
# define PyUnicode_AsUTF8String PyUnicodeUCS4_AsUTF8String
Your error message makes it sound as though your system Python is compiled to use 4-byte-wide Unicode strings (hence why the linker cannot find a UCS2 version of this function inside of it), but that the version of PyEphem that auto-compiled on your system when you ran pip install somehow got confused and unset Py_UNICODE_WIDE and thus generated C code that was expected a UCS2 symbol.
Do you have several compiled versions of Python on your system, where the Unicode setting of one version could accidentally be affecting how this compile for your system Python takes place?
I need to create an OpenGL context in Tkinker, for using it with PyOpenGL Python module.
Tkinker doesn't natively support OpenGL context, but I found this page on PyOpenGL docs, explaining how to use a wrapper included in the module for this:
http://pyopengl.sourceforge.net/documentation/context/
I tried to run the provided code but I got a message saying TOGL module was not found.
I downloaded the module from http://togl.sourceforge.net/, but couldn't get it to work.
PS. I did the test on Mac OS X, with Python 3.2, using virtualenv.
PyOpenGL provides Python bindings for the Tk OpenGL widget (Togl) but not Togl itself, that is why you had to download it. Now, to install Togl is easy but there isn't a tool ready to perform the task. Since the Python bindings will use Tcl to load the Togl module, the widget needs to live in one of the directories present in Tcl's auto_path, which is where Tcl looks for loading libraries. What you can do is start a Tcl interpreter, tclsh, and check which are these directories by doing puts $auto_path. In my case I copied the directory lib/Togl2.0 (inside the Togl's .tar.gz) to /opt/local/lib/tcl8.5. You can also extend auto_path to look for other directories, but I'm not covering that here.
Then I tested using Python 2.7 on Mac OSX. Doing import OpenGL.Tk tries to load Togl, too bad it fails. The reason is that Togl comes precompiled for i386, since I built Python as a universal binary all I did was run it as arch -i386 python2.7, and now import OpenGL.Tk works.
Has anyone found a version of pywin32 for python 3.x? The latest available appears to be for 2.6.
Alternatively, how would I "roll my own" windows API calls in Python 3.1?
You should be able to do everything with ctypes, if a bit cumbersomely.
Here's an example of getting the "common application data" folder:
from ctypes import windll, wintypes
_SHGetFolderPath = windll.shell32.SHGetFolderPathW
path_buf = wintypes.create_unicode_buffer(255)
csidl = 35
_SHGetFolderPath(0, csidl, 0, 0, path_buf)
print(path_buf.value)
Result:
C:\Documents and Settings\All Users\Application Data
There are pywin32 available for 3.0. Python 3.1 was release two days ago, so if you need pywin32 for that you either need to wait a bit, or compile them from source.
http://sourceforge.net/project/showfiles.php?group_id=78018&package_id=79063