Terminal Emulator
I wish to write a terminal emulator in Python. I am a fairly competent Python user, and I wish to try a new project idea. What references can I use when writing my terminal emulator? I wish for it to be a true terminal emulator as well, not just a Tk text widget or something like that. If you have any advice, please do let me know! -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator
We need somethin like a portable curses module (plus colorama) Agreed, getting curses to work on Windows is SUCH a pain, and I don't think I've ever done it. Naturally, as a Linux user, I don't find much need to do it anyway. Colorama would also be cool in the standard library as well. I have worked on projects in the past where only the standard library could be used, so I 100% agree with this. But that's something for the PSF to talk about. Maybe someone could write a PEP for this. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 16/05/2024 01:12, Lawrence D'Oliveiro wrote: On 15 May 2024 10:31:25 GMT, Stefan Ram wrote: We need somethin like a portable curses module (plus colorama) and it has got to work on both Windoze and Linux straight out of the box in standard Python. Something else for Windows Python users to complain that they cannot get to install properly? To be fair, the problem is the fact that they use Windows (but I guess Linux users have to deal with venvs, so we're even. -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
I'm on Manjaro Of course, I'm not here to tell you how to use your computer, and it's great that you're using Linux, but I'd suggest that you look into installing Arch Linux proper. Arch Linux isn't as difficult as people make it out to be (I'd argue that anyone who's had to deal with the Calamares installer has seen worse), and it's hugely rewarding as it gives you a fundamental overview of how your system operates and what makes it tick, since you need to install it yourself manually. Plus, Manjaro holds back packages by about a month or so, sometimes more, which breaks AUR packages, which are designed around Arch Linux's packages, which are newer. On top of this, the Manjaro team just can't be trusted with basic things like not having their SSL certs expire on their website (this has happened half a dozen times in the past, which is embarassing, given that things like certbot make installing a certificate the easiest thing in the world). Again, I'm not some power hungry elitist Arch Linux shill or whatever, it's your computer, use it how you want, these are just my suggestions. Don't say I didn't warn you though :) -- https://mail.python.org/mailman/listinfo/python-list
Re: Terminal Emulator (Posting On Python-List Prohibited)
On 20/05/2024 10:58, Peter J. Holzer wrote: On 2024-05-20 00:26:03 +0200, Roel Schroeven via Python-list wrote: Skip Montanaro via Python-list schreef op 20/05/2024 om 0:08: Modern debian (ubuntu) and fedora block users installing using pip. Even if you're telling it to install in ~/.local? I could see not allowing to run it as root. I assumed pip install --user would work, but no. I tried it (on Debian 12 (bookworm)): $ pip install --user docopt error: externally-managed-environment × This environment is externally managed ╰─> To install Python packages system-wide, try apt install python3-xyz, where xyz is the package you are trying to install. If you wish to install a non-Debian-packaged Python package, create a virtual environment using python3 -m venv path/to/venv. Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make sure you have python3-full installed. If you wish to install a non-Debian packaged Python application, it may be easiest to use pipx install xyz, which will manage a virtual environment for you. Make sure you have pipx installed. See /usr/share/doc/python3.11/README.venv for more information. note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. hint: See PEP 668 for the detailed specification. Exactly the same output for sudo pip install. This message (quoted in all its glory) is too long to be useful. The important bit is at the end: You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages. (I admit I didn't see this the first time I got this message) python3 -m pip install --user --break-system-packages does indeed install into ~/.local/lib/python3.XX/site-packages. This inconvenient, but otoh I have accidentally installed packages into ~/.local in the past, so maybe it's good to make that more explicit. hp Perhaps an alias like so: $ alias 'pip install'='pip install --user --break-system-packages' Would work here? Someone please advise if that is a good idea. -- https://mail.python.org/mailman/listinfo/python-list
Re: Couldn't install numpy on Python 2.7
On 12/06/2024 12:30, marc nicole wrote: I am trying to install numpy library on Python 2.7.15 in PyCharm but the error message I get is: ERROR: Could not find a version that satisfies the requirement numpy (from versions: none) ERROR: No matching distribution found for numpy c:\python27\lib\site-packages\pip\_vendor\urllib3\util\ssl_.py:164: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 fro m configuring SSL appropriately and may cause certain SSL connections to fail. You can upgrade to a newer version of Python to solve this. For more information, see https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings InsecurePlatformWarning, Any clues? Why are you using Python 2? Come on, it's been 16 years. Ya gotta move on at some point. -- https://mail.python.org/mailman/listinfo/python-list
Re: Best (simplest) way to share data between processes
On 06/07/2024 12:32, Stefan Ram wrote: But why overengineer? If you feel comfortable with the file solution, go for it! The only drawback might be that it's a bit slower than other approaches. I absolutely agree. Overengineering is generally a bad idea because you're using a complex solution to solve a simple problem, which leads to unexpected breakage. The file solution is perfectly fine, and file locks are used by really important software (i.e package managers and such) because its simplicity makes it almost never fail. So yeah, go for it! -- https://mail.python.org/mailman/listinfo/python-list
