Broken pyreadline in IPython in MSYS2 - ipython

I have a MSYS2 system, where I've installed python3.5 together with all of its dependencies. Furthermore, I've installed ipython using pip3.5 along with pyreadline 2.1. When I start ipython I get this prompt:
It is broken (as you can see on space between the brackets, and it does not complete any commmands - instead it inserts tabs. Anyone that have a clue what's wrong?

Yes, pyreadline is broken on windows, IPython will move away from readline on the next version (5.0). This should fix things.

Related

python interpreter citing zen of python in the terminal window

I run vscode version 1.65.2.
Today it started citing the whole "The Zen of Python" in the terminal window every time I run a python script in the debugger.
EDIT: It turns out that it is the python interpreter that does it, not vscode. The problem apparently came after I updated ipykernel to version 6.11.0. I run python version 3.9.1 on Windows.
How can I turn it off?
I havent been able to find an answer to this anywhere.
It turned out that an import statement had found its way into my code: "import this as d", and removing it solved the problem. It is a mystery how it ended up there, I certainly haven't put it there knowingly. But problem solved!
That's really odd. I just had the exact same thing. Even the import this as d was on the first line before everything. I use vscode as well. Removing it does help. But I didn't update a kernel prior to this. It happened while I was writing code I think. Python 3.8.10 on Linux.

Intellisense autocomplete not working for wsl in vscode

I've been setting up vscode as an IDE for python development. I use windows subsystem for linux with my python packages installed through anaconda there.
My problem is that auto completion does not work as expected. For examples, outside of wsl if I am using the numpy package I can get autocompletion:
Autocomplete outside of wsl
However, inside of wsl autocomplete does not find numpy.linalg (as in example above):
Autocomplete inside wsl
Thanks in advance!
edit: I am currently using wsl1 if that information is relavent!
As mentioned by #Adriana Hernández you need to install the extensions inside WSL too.
The VSCode WSL docs are covering these here
In short if you go to the extensions tab, you shall see Python marked with "Install in WSL...". Once clicked install and reloaded, it should work.
If not you likely need to pick another interpreter (likely the one from your venv.)
hit Ctrl+Shift+P then
Python: Select interpreter
then select the desired python interpreter (most likely the one in your venv which has all the packages)
What works for me is creating a venv, activating then launching VSCode from WSL with code .
On the first time you will need to install your extensions to WSL, but then it should be good to go.

Jupyter - ending multiline magic command in console

In a Jupyter notebook, a "cell magic" command (prefixed with two percent signs) ends at the end of the cell and is automatically invoked:
But if I try the same thing in the Jupyter console, the command never ends, after any number of blank lines:
That only happens if I invoke IPython as jupyter console, though. If I invoke IPython directly as ipython, the cell magic command completes after one blank line:
For each example, the versions of Python and IPython are identical: Python 3.5.2 and IPython 6.1.0 on one machine (installed with pip), Python 3.4.5 and IPython 5.1.0 on another (installed with Conda).
Is this a bug? Or is there Jupyter default configuration somewhere for IPython that differs from IPython's own default configuration?
Yes, it is a bug, the cell magics are suppose to ends after 2 new lines.
The Jupyter console is way under maintained – we are not aware of many people using it, and it has plenty of issues.
Technically I believe the jupyter console does not use (or respect) the "is_complete" message from the protocol that should tell it wether the snippet of code should be executed or if a newline should be inserted.
You can try to open a bug report, but the fix will probably not be implemented quickly unless someone does a PR.

IPython notebook kernel dies on import

I am running IPython Notebook on Enthought's Canopy 64 bit distribution, Ubuntu 14.04.
I've tried install libtiff, but when I import it in IPython Notebook, the kernel always dies at the import statement. What could possibly be causing this? Canopy is my default Python distribution, my paths all seem like they're set up appropriately, although I'm convinced that something in my Python setup is borked.
Any advice is appreciated.
EDIT: I'll be more specific. Output of sys.path:
['',
'/home/joe/Enthought/Canopy_64bit/User/src/svn',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python27.zip',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/plat-linux2',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-tk',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-old',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/lib-dynload',
'/home/joe/Enthought/Canopy_64bit/User/lib/python2.7/site-packages',
'/home/joe/Enthought/Canopy_64bit/User/lib/python2.7/site-packages/PIL',
'/home/joe/opencv-2.4.9',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/site-packages',
'/home/joe/Canopy/appdata/canopy-1.4.1.1975.rh5-x86_64/lib/python2.7/site-packages/IPython/extensions']
As for how to install Python packages, I assume I go to ~/Enthought/Canopy_64bit/User/lib/python2.7/site-packages and run pip, setup.py, or a shell script, per the specific package's instructions. Is that correct? The article that I linked has the following line: "To install a package which is not available in the Canopy / EPD repository, follow standard Python installation procedures from the OS command line.", which seems to imply that I install per package instructions.
In .bashrc, I have the following:
VIRTUAL_ENV_DISABLE_PROMPT=1 source /home/joe/Enthought/Canopy_64bit/User/bin/activate
export PYTHONHOME=/home/joe/Enthought/Canopy_64bit/User/bin
export PATH=/home/joe/Enthought/Canopy_64bit/User/bin
export PYTHONPATH=/home/joe/Enthought/Canopy_64bit/User/bin
From what I understand of the linked articles, this means I'm setting Canopy User as my default Python distribution. I'm sure I'm doing something a bit over my head here, but I can't understand what else I need to do to fix this issue.
Worse yet, now I'm getting an "ImportError: No module named site" with these .bashrc settings, when trying to start IPython notebook or python from the command line. I can run only from the Canopy GUI.
Closing this. I made it harder than necessary.
It turns out, the PYTHONHOME and PYTHONPATH .bashrc variables were causing some conflicts. Commenting them out seems to have resolved the issue.
Installing outside packages does, indeed, happen from the home (~) directory.

Can't launch IDLE after installing Enthought Canopy

I was previously running Enthought EPD 7.3.2, but switched over to Canopy (academic license). I completely uninstalled EPD before running the Canopy install.
After installing Canopy, I have a shortcut to IDLE in the Canopy start menu folder, but I can't get it to launch (I click it and nothing happens). Tried uninstalling and reinstalling Canopy, but am having the same issue.
Running the 64-bit version of Canopy on Win7, 64bit.
I had a similar problem and found a very simple solution. Try it out and see if it works in your situation too. There is a directory for the Canopy installation:
C:\Users\\AppData\Local\Enthought\Canopy\App\appdata\canopy-1.7.4.3348.win-x86_64\Lib\idlelib
Find “idle.ico” file there, copy and paste it into “Icons” subdirectory.
This fixed the problem!
Canopy 1.0 and 1.0.1 versions have problems with tcl and TKinter, and IDLE doesn't work. This should be fixed in an update, which is just round the corner.
As an afterthought, is there a specific reason you wish to use IDLE? Canopy's editor comes integrated with an IPython console (along with many other goodies), which gives a much better user experience while programming, IMO. (Disclaimer: I work for Enthought)