Re: Is npyscreen still alive?
On 4/24/23 11:32, Grant Edwards wrote: On 2023-04-24, Grant Edwards wrote: The other big advantage of an ncurses program is that since curses support is in the std library, a curses app is simpler to distribute. Right now, the application is a single .py file you just copy to the destination machine and run. It supports command-line use and a Tk GUI. I can add an ncurses "CUI" without having to either adopt a more complex bundling mechanism that requires it to be "installed" or require that users install dependencies via pip/apt/yum/whatever. However... I just realized that Python's curses support is missing two huge chunks: both menu and form support are not there. I guess that explains why people feel the need to write high-level UI wrappers for Python curses: the high level stuff that curses does support is missing from the Python bindings. Adding a curses UI for my app might not be feasible after all... -- Grant That's because the Gods Of Ancient Internets knew that all you ever really need is VT220 escape sequences ... unless you are one of the heathens that still program in HLLAPI on 327x machinery (I kid, I kid, NO one needs that pain ...) -- https://mail.python.org/mailman/listinfo/python-list
Re: Is npyscreen still alive?
On 4/24/23 09:14, Stefan Ram wrote: Grant Edwards writes: The other big advantage of an ncurses program is that since curses support is in the std library, a curses app is simpler to distribute. IIRC curses is not in the standard library /on Windows/. I miss a platform independent (well, at least for Linux, Mac, and Windows) package with curses features in the standard library. That's correct (or was, last time I looked). For this reason, I resorted to using tkinter for the twander file browser. While it works, the code needs a complete rethink and to be written to be Python3 compatible. Perhaps when/if that happens, something like Textual need serious consideration. tkinter works, but is showing its age. So a fresher look without all the burden of X and or requiring a browser, while also giving you that option is appealing. -- https://mail.python.org/mailman/listinfo/python-list
[Python-announce] python-oracledb 1.3.1
What is python-oracledb? python-oracledb is a Python extension module that enables access to Oracle Database for Python and conforms to the Python database API 2.0 specifications with a number of enhancements. This module is intended to eventually replace cx_Oracle. Where do I get it? https://pypi.org/project/oracledb/1.3.1/ The easiest method to install/upgrade python-oracledb is via pip as in python -m pip install oracledb --upgrade What's new? This release addresses a number of reported issues. See the full release notes for all of the details: https://python-oracledb.readthedocs.io/en/latest/release_notes.html#oracledb-1-3-1-april-2023 Please provide any feedback via GitHub issues: https://github.com/oracle/ python-oracledb/issues or discussions: https://github.com/oracle/python- oracledb/discussions ___ Python-announce-list mailing list -- python-announce-list@python.org To unsubscribe send an email to python-announce-list-le...@python.org https://mail.python.org/mailman3/lists/python-announce-list.python.org/ Member address: arch...@mail-archive.com
Re: Is npyscreen still alive?
On 4/24/23 08:04, Grant Edwards wrote: > Is putty running on Windows a "modern terminal emulator" in this > context? After observing some of the local IT types work, I suspect > that will be a common use-case for the app I'm working on. Yes, Putty qualifies as a "modern terminal emulator." It supports UTF-8 and unicode fonts. And the mouse events work as well. The only catch is the default font is courier new which seems to not have some of the line drawing characters in it. But if I change to something like Cascadia Code it looks very good. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is npyscreen still alive?
On 2023-04-24, Mats Wichmann wrote: > On 4/24/23 10:32, Grant Edwards wrote: > >> However... I just realized that Python's curses support is missing two >> huge chunks: both menu and form support are not there. I guess that >> explains why people feel the need to write high-level UI wrappers for >> Python curses: the high level stuff that curses does support is >> missing from the Python bindings. >> >> Adding a curses UI for my app might not be feasible after all... > > I guess it's also worth mentioning that Python curses doesn't work out > of the box on Windows - because the actual curses library isn't commonly > present on Windows. It's not hard to get hold of builds (check PyPI) but > that means it's no longer "standard". That's a good point. I neglected to mention that the use case for curses UI app is to run on headless Linux servers. It needs to work when run on a Linux by a user logged in via Putty on Windows, but I have no need to execute the application in curses-mode on Windows. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Python curses missing form library?
On 2023-04-24, Alan Gauld wrote: > On 24/04/2023 17:26, Grant Edwards wrote: >> Does the Python curses support in the standard library not include >> support for the curses form library? It seems to include support for >> the panel library, but I can't find any mention of the form library. > > I don't believe so. If you are building terminal based form-type > apps the best bet seems to be urwid. I haven't used it in anger > but the beginner docs I saw looked promising. urwid does indeed look nice, but it would require doing the whole bundling and installing thing. I was hoping to avoid that by sticking with stdlib and curses. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Is npyscreen still alive?
On 4/24/23 10:32, Grant Edwards wrote: On 2023-04-24, Grant Edwards wrote: The other big advantage of an ncurses program is that since curses support is in the std library, a curses app is simpler to distribute. Right now, the application is a single .py file you just copy to the destination machine and run. It supports command-line use and a Tk GUI. I can add an ncurses "CUI" without having to either adopt a more complex bundling mechanism that requires it to be "installed" or require that users install dependencies via pip/apt/yum/whatever. However... I just realized that Python's curses support is missing two huge chunks: both menu and form support are not there. I guess that explains why people feel the need to write high-level UI wrappers for Python curses: the high level stuff that curses does support is missing from the Python bindings. Adding a curses UI for my app might not be feasible after all... -- Grant I guess it's also worth mentioning that Python curses doesn't work out of the box on Windows - because the actual curses library isn't commonly present on Windows. It's not hard to get hold of builds (check PyPI) but that means it's no longer "standard". -- https://mail.python.org/mailman/listinfo/python-list
Re: Python curses missing form library?
On 24/04/2023 17:26, Grant Edwards wrote: > Does the Python curses support in the standard library not include > support for the curses form library? It seems to include support for > the panel library, but I can't find any mention of the form library. I don't believe so. If you are building terminal based form-type apps the best bet seems to be urwid. I haven't used it in anger but the beginner docs I saw looked promising. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman/listinfo/python-list
Re: Is npyscreen still alive?
On 2023-04-24, Grant Edwards wrote: > The other big advantage of an ncurses program is that since curses > support is in the std library, a curses app is simpler to > distribute. Right now, the application is a single .py file you > just copy to the destination machine and run. It supports > command-line use and a Tk GUI. I can add an ncurses "CUI" without > having to either adopt a more complex bundling mechanism that > requires it to be "installed" or require that users install > dependencies via pip/apt/yum/whatever. However... I just realized that Python's curses support is missing two huge chunks: both menu and form support are not there. I guess that explains why people feel the need to write high-level UI wrappers for Python curses: the high level stuff that curses does support is missing from the Python bindings. Adding a curses UI for my app might not be feasible after all... -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Python curses missing form library?
Does the Python curses support in the standard library not include support for the curses form library? It seems to include support for the panel library, but I can't find any mention of the form library. I see in the docs that menu support is still missing. :/ -- Grant -- https://mail.python.org/mailman/listinfo/python-list
JOB | Linux Platform Engineer (India and Singapore)
Hello, i'm working with an employer that is looking to hire a Linux platform engineer for their office in India and Singapore that has experience in automation and management of platform configuration from both an onprem and cloud perspective. Consequently, I had hoped that some members may like to discuss further; off-list. I can be reached using "JamesBTobin (at) Gmail (dot) Com". Kind regards, James -- https://mail.python.org/mailman/listinfo/python-list
Re: Incomplete sys.path with embeddable python (Windows)!?
Ralf M. ha scritto:
Am 22.04.2023 um 03:27 schrieb Greg Ewing via Python-list:
How are you invoking your script? Presumably you have some code
in your embedding application that takes a script path and runs
it. Instead of putting the code to update sys.path into every
script, the embedding application could do it before running
the script.
In principle a good idea, but I don't know how to do that:
The script is currently invoked by a .cmd file, but that may change to a
shortcut (.lnk). This is what the embeddable package documentation calls
"Python Application - simple approach".
To update sys.path on start up I would need to do something like
C:\path\to\python.exe --add-path C:\s-path C:\s-path\script.py
but I couldn't find an option like --add-path.
what about:
foo.py:
from sys import path
print('path:', path)
#end foo.py
from prompt:
$ python -c "import sys;sys.path=['/user/foopath']+sys.path;import foo;foo"
output:
path: ['/user/foopath', '', '/usr/lib/python39.zip',
'/usr/lib/python3.9', '/usr/lib/python3.9/lib-dynload',
'/usr/lib/python3.9/site-packages']
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is npyscreen still alive?
On 2023-04-24, Michael Torrie wrote: > On 4/21/23 15:57, Barry wrote: > >> Maybe this, recently lwn.net article, >> https://textual.textualize.io/ I was planning to check it out. > > Textual definitely looks slick and modern. And with a modern > terminal emulator it works quite well and is responsive. I'd > definitely consider it for a TUI. > > But on the Linux console, or on an older terminal, not so much. > Textual's really designed for smallish unicode fonts in a windowed > environment, not any kind of real, old-school text mode. Just > something to keep in mind. 99% of terminal users are using a modern > terminal emulator these days, with full color and unicode, which is > the target of textual. Is putty running on Windows a "modern terminal emulator" in this context? After observing some of the local IT types work, I suspect that will be a common use-case for the app I'm working on. > Curses-based programs don't look great on anything, but they do look > consistent on more primitive terminals. The other big advantage of an ncurses program is that since curses support is in the std library, a curses app is simpler to distribute. Right now, the application is a single .py file you just copy to the destination machine and run. It supports command-line use and a Tk GUI. I can add an ncurses "CUI" without having to either adopt a more complex bundling mechanism that requires it to be "installed" or require that users install dependencies via pip/apt/yum/whatever. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Is npyscreen still alive?
On 4/21/23 15:57, Barry wrote: > Maybe this, recently lwn.net article, https://textual.textualize.io/ > I was planning to check it out. Textual definitely looks slick and modern. And with a modern terminal emulator it works quite well and is responsive. I'd definitely consider it for a TUI. But on the Linux console, or on an older terminal, not so much. Textual's really designed for smallish unicode fonts in a windowed environment, not any kind of real, old-school text mode. Just something to keep in mind. 99% of terminal users are using a modern terminal emulator these days, with full color and unicode, which is the target of textual. Curses-based programs don't look great on anything, but they do look consistent on more primitive terminals. -- https://mail.python.org/mailman/listinfo/python-list
