I am new to transcrypt. I created a test python file,test.py
def test_def(a: list):
for i in range(len(a)):
print(i)
xx = [2, 3, 4]
test_def(xx)
I have python 3.9. If I run the python file, it runs and prints as expected.
Running transcrypt gives following error
> python -m transcrypt -b -m -n .\test.py
Error while compiling (offending file last):
File 'test', line 2, namely:
Error while compiling (offending file last):
File 'test', line 2, namely:
Aborted
I am not sure what it expects and why is it giving the error, any help would be appreciated.
What version of Transcrypt are you using? Wasn't able to replicate the error using Python 3.9.0 and Transcrypt 3.9.0. You can check like this (Win):
> transcrypt -h | find "Version"
# and may as well double check that the right version of python was used:
> python --version
The Python and Transcrypt versions should match, as Transcrypt uses Python's AST that may change between versions.
Another aspect is that I first installed Transcrypt into a virtual env as follows (Win):
> py -3.9 -m venv wenv
> wenv\Source\activate.bat
> pip install transcrypt
> python -m transcrypt -b -m -n test.py
It sometimes happens that one inadvertently uses the wrong version of Python. 'py' is the Python launcher on Windows and useful to launch the right version if you have multiple versions installed. On Linux there are typically binaries in /usr/bin such as 'python3.9' or a symlink such as 'python3' that links to the most recent 3 version. Installing into a virtual env as demonstrated is also helpful, as various problems can come about otherwise.
The above compiled test.py without error (Win 10 cmd.exe). Fwiw, the file was saved as utf-8 and compile worked with and without a BOM.
Related
When I am using repo init to initialize some repo from a source, I keep getting:
Traceback (most recent call last):
File "/home/workspace/.repo/repo/main.py", line 56, in <module>
from subcmds.version import Version
File "/home/workspace/.repo/repo/subcmds/__init__.py", line 38, in <module>
['%s' % name])
File "/home/workspace/.repo/repo/subcmds/upload.py", line 27, in <module>
from hooks import RepoHook
File "/home/workspace/.repo/repo/hooks.py", line 472
file=sys.stderr)
^
SyntaxError: invalid syntax
The following are the python versions I have:
python -V -> 2.7
python3 -V -> 3.6
According to this link, python 3.6 is required starting with repo-1.14 but I'm not certain if that's what my repo version is - didn't have any luck finding a way around determining the version.
Looks like you are running an old repo launcher script version that is incompatible with the latest repo version. To fix this, download the latest repo launcher python script from Google and replace your outdated one.
The launcher script is the executable python script called "repo" and is located in your PATH, usually ~/bin (according to Google's instructions) or ~/.local/bin/. To find out where yours is located, type which repo in the terminal and it will print the script's location.
Let's say your repo script is in ~/bin. To download the script (and make it executable), you can do:
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo
Also, you do not need to remove Python 2.7 for repo to work. I use Ubuntu 18.04 and have both Python 2.7 and 3.6 installed as well, and repo runs fine.
Since updating from Homebrew Python 2.7.11 (from 2.7.10) I'm suddenly unable to test register my package on PyPi from the PyCharm IDE console.
Running (as an "External Tool")
python -B setup.py register -r pypitest
I now get
Traceback (most recent call last):
File "setup.py", line 22, in <module>
from setuptools import setup
File "/usr/local/lib/python2.7/site-packages/setuptools/__init__.py", line 12, in <module>
from setuptools.extension import Extension
File "/usr/local/lib/python2.7/site-packages/setuptools/extension.py", line 8, in <module>
from .dist import _get_unpatched
File "/usr/local/lib/python2.7/site-packages/setuptools/dist.py", line 16, in <module>
from setuptools.depends import Require
File "/usr/local/lib/python2.7/site-packages/setuptools/depends.py", line 6, in <module>
from setuptools import compat
File "/usr/local/lib/python2.7/site-packages/setuptools/compat.py", line 17, in <module>
import httplib
File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 80, in <module>
import mimetools
File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/mimetools.py", line 6, in <module>
import tempfile
File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tempfile.py", line 32, in <module>
import io as _io
File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
import _io
ImportError: dlopen(/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
Referenced from: /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
Expected in: flat namespace
in /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
Process finished with exit code 1
I'm not sure how to proceed. I only get this issue if I execute from within my IDE's console. If I do it directly at the system command line (Terminal on OS X) I have no problems.
OS X 10.11.3; Homebrew Python 2.7.11; PyCharm 5.0.3
tl;dr: Fix this issue by doing one of the following:
type hash -r python, OR
log out and log in.
EDIT: An answer to my related question makes it clear what's happening here. When you install a new version of python, you may need to run hash -r python to tell bash to reset the "cached" location to the python executable.
In my case, I was typing python, which was on my $PATH at /usr/local/bin/python. But bash was still using the old cache location /usr/bin/python. So, the old executable was called, but the new path was provided to python in sys.argv[0]. This means that the old executable was running, but the new sys.executable value caused all the wrong modules to get loaded (including the io module).
I'm having the same problem. I installed python 2.7.11 via an installer from Python.org. Strangely, the issue seems to be related to some subtle difference between how OSX launches python when I invoke it from the shell using the full path vs. using just the word python.
So, for me, this works (invoking python via the full path /usr/local/bin/python):
$ which python
/usr/local/bin/python
$ /usr/local/bin/python -c "import io"
$
... but this doesn't:
$ python -c "import io"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
import _io
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
Expected in: flat namespace
in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
So, as a workaround, you can try doing the same thing.
Elsewhere, I've posted a separate question about this puzzling behavior. Maybe somehow merely calling python invokes some strange mix of the 2.7.11 executable with the 2.7.10 dylibs??
According to https://github.com/klen/python-mode/issues/634:
I had the same issue, but successfully fixed. In my case I compiled
python and vim with homebrew, when PYTHON_PATH has been specified and
set to one of my dev environments, where I also had some libraries,
including io. Workaround was simple: open new terminal, make sure that
you do not have custom PYTHON_PATH, uninstall python, uninstall vim.
Reinstall both of them.
and
Problem solved.
Culprit is the update from python 2.7.10 to 2.7.11.
If you are using conda package control, simply run "conda install
python=2.7.10" will solve this problem.
This doesn't give the root cause though. Since this happens with _io, this looks like a bug in python 2.7.11 (unlikely, there would be a world-scale outcry and a prompt fix if it was) or some packaging bug or version mismatch specifically with the homebrew version (and maybe some related ones, too).
Try to import _io in the console and if it succeeds, check if it was loaded from the same path.
Reinstall python.
brew unlink python && brew reinstall python
Secure the path
export PYTHONPATH=$PYTHONPATH:/usr/local/bin/
BACKUP and Change the order of "paths" file.
sudo nano /etc/paths
it seems, the order of paths, it is decisive to run python properly. In my case, the result was:
#sudo nano /etc/paths
/usr/bin
/usr/local/bin
/bin
/usr/sbin
/sbin
On my mac, path is like this.
$ which python
/usr/local/bin/python
Now I can run both:
$ /usr/local/bin/python -c "import io"
$ python -c "import io"
I had the same issue, it is successfully fixed by just replacing the _io.so file.
sudo find / -name _io.so
copy the path of the _io.so file which DOES NOT belong to python-2.7.11. For example, copy the path of _io.so which is under python-2.7.5:
/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
Replace the /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so file with the _io.so that you just found.
This happened to me as well in MacVim. I solved it by making sure :python print(sys.path) is using system Python (e.g. /Library/Python/2.7/...)
Since I installed MacVim via Homebrew, I just did that by:
Spawn a new shell that had which python -> /usr/bin/python. For my case I needed to remove the pyenv line from my .bash_profile. If you installed Python via Homebrew you may want to brew unlink python first
brew reinstall macvim
If your problem is caused by anaconda, it is unnecessary to remove //anaconda directory.
Just open your ~/.bash_profile, find the line
export PATH="//anaconda/bin:$PATH
and comment it out, then restart your terminal session.
Another quick workaround if you don't mind sticking with Python 2.7.10 is to specify the path of the Python interpreter executable that will be used for the virtualenv. On OSX that path is usually /usr/bin/python:
virtualenv venv --python=/usr/bin/python
Can't add comment (?) so this just to share my exp., downgrade to 2.7.10 works fr me.
I got this error after a failed NLTK download, I needed to uninstall anaconda:
sudo rm -rf ~/anaconda
update PATH variable
This happened when I already had tried to create a venv in a folder, and mistakenly was trying to initialize a second one! So I just removed venv directory and re-ran the command. Very likely this is not the answer to this solution, but searching my error brought me here, so it may help some others who are stuck.
I solved this issue by removing the symbolic link that was in /usr/local/bin and copying the actual python binary, that was pointed to by said link, there.
I had the same issue when I tried to use PyCharm. Solved by setting "python interpreter" in project configuration to point to the python virtual env I wanted to use, which was an Anaconda env. Somehow the interpreter path was missing the "anaconda" portion of ~/.../anaconda/.../_io.so. No need to uninstall anaconda.
I installed Python 3.5 using MacPorts. I am trying to use SublimeText3 as an editor. (Anything better and more integrated tan ST3 for python development??)
From the MacOSX terminal, I can 'import numpy' just fine, but SublimeText3 cannot find the packages.
Is it because the python packages are installed as 'Frameworks'?, because the Path for finding those modules is not right?, other????
Here's what terminal shows:
$ type -a python3
python3 is /opt/local/bin/python3
python3 is /Library/Frameworks/Python.framework/Versions/3.5/bin/python3
python3 is /Library/Frameworks/Python.framework/Versions/3.5/bin/python3
python3 is /usr/local/bin/python3
Here's what ST3 shows:
File "/Users/xxx/Desktop/python_work/array_play.py", line 1, in <module>
import numpy
ImportError: No module named 'numpy'
[Finished in 0.0s with exit code 1]
[cmd: ['/Library/Frameworks/Python.framework/Versions/3.5/bin/python3', '-u', '/Users/xxx/Desktop/python_work/array_play.py']]
[dir: /Users/xxx/Desktop/python_work]
[path: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin::/Library/Frameworks/Python.framework/Versions/3.5/bin/python3/site-packages]
As you can see, I tried to add
/opt/local/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages
to the Path variable, since this is the location of the numpy folder, but this doesn't work...
Should I just ignore this message in ST3 and use it only as an editor??? Seems rather silly to have an IDE and not be able to build and run programs from it...
First, you need to find out which python3 you are using in terminal. You can do this by running command which python3. Suppose the output is: /Users/username/.anaconda3/bin/python3.
Second, try to set PYTHONPATH environment variable in Sublime's settings. Go to Preferences -> Settings User, and add the following lines at the end of the settings file (but inside of the last } symbol).
"env":
{
"PYTHONPATH":"/Users/username/.anaconda3/bin"
}
I installed Python 3.4.2 and Virtualenv 12.0.5 in my Linux Mint 17.1
Then I tried creating:
$ virtualenv venv
And also using --clear and/or -p /usr/bin/python3.4, always getting the messages:
Using base prefix '/usr'
New python executable in venv/bin/python3
Also creating executable in venv/bin/python
ERROR: The executable venv/bin/python3 could not be run: [Errno 13] Permission denied
Another try was:
$ pyvenv-3.4 venv
It gave no errors on creation, but in the venv/bin file the python3.4 is a symbolic link to /usr/local/bin/python3.4. Then when I activate and install any lib using pip or pip3, then try to import it, I get the error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named 'anymoduledownloaded'
I always used virtualenv in Python 2.X and never got this kind of errors. Any thoughts on what am I doing wrong?
Thanks!!
=======EDITED=======
This is the output of my partitions (fdisk -l):
Device Boot Start End Blocks Id System
/dev/sda1 2048 98707455 49352704 83 Linux
/dev/sda2 303507456 3890644991 1793568768 5 Extended
/dev/sda3 * 98707456 303507455 102400000 7 HPFS/NTFS/exFAT
/dev/sda4 3890644992 3907028991 8192000 82 Linux swap / Solaris
/dev/sda5 303509504 3890644991 1793567744 7 HPFS/NTFS/exFAT`
And also my fstab:
<file system> <mount point> <type> <options> <dump> <pass>
-> was on /dev/sda1 during installation
UUID=a38f9c6d-3cd9-4486-b896-acbc6182ec61 / ext4 errors=remount-ro 0 1
-> swap was on /dev/sda4 during installation
UUID=efad7b53-79a8-4230-8226-9ca90c68ea9d none swap sw 0 0`
Is that a shared partition that you have mounted? Does the shared partition have a different filesystem then the non-shared one you tried upon? If yes, then IMO, that will definitely cause an error since you are making and compiling binaries for python on one filesystem, and so it will not work on another filesystem.
As mentioned in this answer, adding to your /etc/fstab with an entry with exec flag might make it work for you, i.e., you might need to add another entry for the NTFS disk here to make it automount:
<file system> <mount point> <type> <options> <dump> <pass>
-> was on /dev/sdaX during installation
UUID=<uid_of_NTFS> / ntfs auto,user,exec,nodev,rw,errors=remount-ro 0 1
I struggled with this as well so I wrote an ugly bash script to help me with this. The only salient difference between what you do and what I do is on line 133:
/path/to/python/bin/python3.4 /path/to/python/bin/pyvenv /path/to/venv
That is, explicitly name the instance of python and the venv tool. Then
/path/to/venv/bin/pip install django # or whatever
Edit
I installed Linux Mint in a VM to try and build a Python 3.4 virtual environment. Based on the error messages I saw and this answer, I learned that I must do the following to get a complete Python 3.4 build:
apt-get install build-essential libssl-dev openssl
Without this, my Python 3.4 build did not contain pip. Note that you probably want to install readline and other development packages.
Unsolicited Advice
Do not do this as root, create a user dedicated to running your venv
Create a script to create your environment
Check that script into your source code repo
I deleted my python binaries and venvs multiple times and then recreated all of with this script to make sure that my script reproduced my environment and then stripped the identifying information and saved that on github to share it. I should really be using a more formal tool for this like docker/puppet/chef.
I'm working on several Python projects who run on various versions of Python. I'm hoping to set up my vim environment to use ropevim, pyflakes, and pylint but I've run into some issues caused by using a single vim (compiled for a specific version of Python which doesn't match the project's Python version).
I'm hoping to build vim into each of my virtualenv directories but I've run into an issue and I can't get it to work. When I try to build vim from source, despite specifying the Python config folder in my virtualenv, the system-wide Python interpreter is always used.
Currently, I have Python 2.6.2 and Python 2.7.1 installed with several virtualenvs created from each version. I'm using Ubuntu 10.04 where the system-default Python is 2.6.5. Every time I compile vim and call :python import sys; print(sys.version) it returns Python 2.6.5.
configure --prefix=/virtualenv/project --enable-pythoninterp=yes --with-python-config-dir=/virtualenv/project/lib/python2.6/config
Results in the following in config.log:
...
configure:5151: checking --enable-pythoninterp argument
configure:5160: result: yes
configure:5165: checking for python
configure:5195: result: /usr/bin/python
...
It should be /virtualenv/project/bin/python. Is there any way to specify the Python interpreter for vim to use?
NOTE: I can confirm that /virtualenv/project/bin appears at the front of PATH environment variable.
I'd recommend building vim against the 2 interpreters, then invoking it using the shell script I provided below to point it to a particular virtualenv.
I was able to build vim against Python 2.7 using the following command (2.7 is installed under $HOME/root):
% LD_LIBRARY_PATH=$HOME/root/lib PATH=$HOME/root/bin:$PATH \
./configure --enable-pythoninterp \
--with-python-config-dir=$HOME/root/lib/python2.7/config \
--prefix=$HOME/vim27
% make install
% $HOME/bin/vim27
:python import sys; print sys.path[:2]
['/home/pat/root/lib/python27.zip', '/home/pat/root/lib/python2.7']
Your virtualenv is actually a thin wrapper around the Python interpreter it was created with -- $HOME/foobar/lib/python2.6/config is a symlink to /usr/lib/python2.6/config.
So if you created it with the system interpreter, VIM will probe for this and ultimately link against the real interpreter, using the system sys.path by default, even though configure will show the virtualenv's path:
% PATH=$HOME/foobar/bin:$PATH ./configure --enable-pythoninterp \
--with-python-config-dir=$HOME/foobar/lib/python2.6/config \
--prefix=$HOME/foobar
..
checking for python... /home/pat/foobar/bin/python
checking Python's configuration directory... (cached) /home/pat/foobar/lib/python2.6/config
..
% make install
% $HOME/foobar/bin/vim
:python import sys; print sys.path[:1]
['/usr/lib/python2.6']
The workaround: Since your system vim is most likely compiled against your system python, you don't need to rebuild vim for each virtualenv: you can just drop a shell script named vim in your virtualenv's bin directory, which extends the PYTHONPATH before calling system vim:
Contents of ~/HOME/foobar/bin/vim:
#!/bin/sh
ROOT=`cd \`dirname $0\`; cd ..; pwd`
PYTHONPATH=$ROOT/lib/python2.6/site-packages /usr/bin/vim $*
When that is invoked, the virtualenv's sys.path is inserted:
% $HOME/foobar/bin/vim
:python import sys; print sys.path[:2]
['/home/pat/foobar/lib/python2.6/site-packages', '/usr/lib/python2.6']
For what it's worth, and no one seems to have answered this here, I had some luck using a command line like the following:
vi_cv_path_python=/usr/bin/python26 ./configure --includedir=/usr/include/python2.6/ --prefix=/home/bcrowder/local --with-features=huge --enable-rubyinterp --enable-pythoninterp --disable-selinux --with-python-config-dir=/usr/lib64/python2.6/config
I would like to give a similar solution to crowder's that works quite well for me.
Imagine you have Python installed in /opt/Python-2.7.5 and that the structure of that folder is
$ tree -d -L 1 /opt/Python-2.7.5/
/opt/Python-2.7.5/
├── bin
├── include
├── lib
└── share
and you would like to build vim with that version of Python. All you need to do is
$ vi_cv_path_python=/opt/Python-2.7.5/bin/python ./configure --enable-pythoninterp --prefix=/SOME/FOLDER
Thus, just by explicitly giving vi_cv_path_python variable to configure the script will deduce everything on it's own (even the config-dir).
This was tested multiple times on vim 7.4+ and lately with vim-7-4-324.
I was having this same issue with 3 different versions of python on my system.
for me the easiest thing was to change my $PATH env variable so that the folder that has the version of python I wanted was (in my case /usr/local/bin) was found before another.
During my compiling vim80, the system python is 2.6, I have another python 2.7 under ~/local/bin, I find that, to make the compiling work:
update $PATH to place my python path ahead
add a soft link, ln -s python python2 ( the configure file would try to locate python config by probing python2 )
make distclean before re-run ./configure to make sure no cached wrong value is picked.