PyDev has its own jython interpreter, inside pydev.jython.VERSION
that jython has its own python libraries i.e. pydev.jython.VERSION/LIB/zipfile.py
Now if I write a jython script for pydev-jython-scripting, it will load only its internal Lib pydev.jython.VERSION/LIB/
How do I have this pydev-jython recognize PYTHONPATH, I tried appending to sys.path but there is some python version problem some invalid syntax
My system python installation has all the .py source, my pydev interpreter configuration has python interpreter setup and NOT jython and NOT ironpython
pydev-jython script does not recognize many of regular system python modules, why?
The version that PyDev uses internally is Jython 2.1, so, you can't add newer libraries to that version unless they're compatible...
If you need to use a different version, you'd need to first update the version used inside PyDev itself (it wasn't updated so far because the current Jython size is too big -- PyDev has currently 7.5 MB and just the newer Jython jar is 10 MB -- with libs it goes to almost 16 MB, so making PyDev have 22 MB just for this upgrade is something I'm trying to avoid... now, I think there's probably too much bloat there in Jython, so, if that can be removed, it's something that may be worth revisiting...).
Related
I've been writing C extensions to Python for a while, but have been on other tasks for the past year or so. It looks like I'm going to come back to this soon, but in the meantime I've upgraded my Mac to Mavericks. And of course, suddenly, EEK! GDB is gone! And I can't find a startup file for LLDB (like the existing GDB version in Misc/gdbinit) that knows how to reach into the CPython interpreter and tell me about objects. (Or any easy Emacs-LLDB integration like I had with GDB.)
What's the consensus on the best way to debug C extensions now? Go build a custom GDB? Learn LLDB and write my own integration? Use some IDE that 'just does' all this? Just stop trying to do this on a Mac and do it in Linux instead?
(Just to make things even more fun, I need to do this in Python 2.6 to be compatible with our existing RHEL installations... which means I also need to fix the readline bug that causes Python 2.6 to crash on Mavericks -- and that's how I discovered these issues. Sigh.)
Maybe I am missing something, but I just downloaded pypy 2.0 beta2 windows binary (32 bit), and it seems I can run the interpreter by executing pypy.exe. However, I would like pypy to work with pyscripter and for all my old libraries to be available. Is this possible? Or is it as if I just installed a new version of python (so I would need to install all of my libraries again)? I might be confused at a fundamental level.
Thanks!
It's not "as if". :-) You installed a new version of Python. Yes, you will have to install all your libraries again.
It seems you tell PyScripter which Python it uses for debugging with the PYTHONHOME variable. Try this:
SET PYTHONHOME=C:\<PathtoPyPy>
PyScripter --PYTHON27 --PYTHONDLLPATH "C:\<PathtoPyPy>" %1 %2 %3 %4 %5
PyCharm Community edition IDE by JetBrains supports pypy, or any other interpreter
Just go to File > Settings > Project INterpreter and set interpreter location
I'm a newbie programmer just installing Python 3.2, but I know I also have an older version of Python on my machine. in fact, I think Macbook comes with it installed. Do I have to worry about having different versions on my computer when I try to start learning Python?
For the most part, you don't have to worry about conflicts with system Python. In fact it is recommended to install a different Python version instead of working with system Python. Also consider using virtualenv and virtualenvwrapper to maintain any dependencies for each project easily without conflicts.
It really depends what OS you're talking about. I'm assuming you're talking about a Mac, since you mentioned Macbook.
Macs come with 2.5 and 2.6 installed as far as I'm aware. At least mine has both those versions, and I've only installed 2.7 manually.
You can check which version of python is the current 'system' python by doing the following in terminal:
// check the version of system python
python --version
// tells you where the system version of python is on your PATH
which python
On *nix type Operating Systems, like your Mac, applications aren't really 'installed', like they are in Windows (eliding details). Instead, application files are placed in various different parts of the file system. Python, for example, is placed into the following directory (by default) when installing 2.7:
/Library/Frameworks/Python.framework/Versions/2.7/bin/python
Since this directory isn't on the system PATH, this version of python won't be used when simply calling python from the command line. The system will search all the folders in the PATH environment variable for an executable file called python. It will usually find it in /usr/bin/ or something similar.
To make a new version of Python the 'system' python, you have a couple of options:
Modify your .bash_profile, and prepend the path to your new python to the PATH environment variable.
symlink the new version of python to a directory already on your PATH like /usr/bin/
Be aware that Mac python installers can modify your .bash_profile (in your home directory), to force the new version to be the default system version. This is what my bash_profile shows:
# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH="/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}"
export PATH
You can happily run multiple versions of python on the same system. A particular version is usually the default though, and that's whatever executable python file is found on the PATH first.
If you want to use a different version at any particular point in time, you can:
/path/to/python/2.4/python some_script.py
/path/to/python/2.7/python some_script.py
/path/to/python/3.2/python some_script.py
That will execute the script some_script.py under 3 different versions of python. Of course, you need to make sure that the /path/to/python is correct.
So yes, you need to be mindful about what version of python you are going to be using, hopefully this will guide you into understanding how applications are installed and which version of an application is launched by default when you don't provide a path.
Yes, 3.x Python syntax is not backward-compatible with 2.x. So if you learn Python 3.x you might not be able to port your knowledge to Python 2.x.
Moreover you should choose if you want to learn 3.x or 2.x. 2.x is far more widespread than 3.x, but 3.x is where Python is heading. No more innovation will happen in 2.x, and in mid-term most frameworks will be ported to 3.x (right now there are some notable exceptions)
Hope that helps!
In general, you should be fine. Since the Mac is BSD-based, it should maintain the "python" command as pointing to the version that your system requires, which is usually an older version like 2.5. You may have to use a command like python3 to run your Python 3 programs, but other than that it should be transparent to you.
As you learn and become more advanced, you can begin using the virtualenv system to maintain separate Python installations for multiple projects.
Python version with different major or minor version numbers can be installed in parallel. For example, you can have 2.4, 2.5, 2.6, 2.7 and 3.1 on the same machine. However, you can't have versions with the same major and minor number installed at the same time (at least, not without tricks), so you can't have 2.5.2 and 2.5.4 at the same time.
Note that you will have to install any third-party libraries once for every Python version.
It is very well possible to have multiple versions of python on your machine. Just make sure, that if you call python in your console it uses the python you want it to use. Same goes for your IDE.
Regarding the version: It is always nice to have the latest version on board (in python however there are compatibility issues to take into account) , since there might be features you want to use, that are only available with a certain version and upwards. Since this is sometimes tricky to find out, especially if you are new to the field, going with the latest version might be how you should proceed.
Be careful before installing new version of python.
Python has no backward compatibility.
Scripts written for python 2.7.* won't work on python 3
For example,
print "Hello" will work on python 2.7 but not on version3
I have Mercurial 1.3 installed on my Windows 7 machine. I don't have python installed, but Mercurial seems to be OK with that.
How does it work?
Also, is it possible to force Mercurial run on IronPython and will it be compatible?
Thank you.
The Mercurial windows installer is packaged using py2exe. This places the python interpreter as a DLL inside of a file called "library.zip".
On my machine, it is placed in "C:\Program Files\TortoiseHg\library.zip"
This zip file also contains the python libraries that are required by mercurial.
For a detailed description of how mercurial is packaged for windows, see the developer page describing building windows installer.
Since there is a "library.zip"(9MB), Mercurial's Windows binary package maybe made by py2exe, py2exe is a Python Distutils extension which converts Python scripts into executable Windows programs, able to run without requiring a Python installation.
Others have answered the first question -- let me give a guess about the second part.
Mercurial will normally use some C extensions for speed. You cannot use those with IronPython.
But we also ship pure Python versions of these modules, and depending on how much IronPython implements of a standard Python 2.4 environment, those modules could be compatible. I have seen reports on IRC about Jython (the Java port of Python) being able to do a few operations using the pure modules. You should download Mercurial and take a look at the mercurial/pure folder. These modules simply has to be moved up one directory level to be found, the setup.py script can do this if you pass the --pure flag. Please see its source or come talk with us on the Mercurial mailinglist/IRC.
Mercurial bundles the necessary python binaries within it, I believe.
I'm currently toying with python at home and I'm planning to switch to python 3.1. The fact is that I have some scripts that use python 2.6 and I can't convert them since they use some modules that aren't available for python 3.1 atm. So I'm considering installing python 3.1 along with my python 2.6. I only found people on the internet that achieve that by compiling python from the source and use make altinstall instead of the classic make install. Anyway, I think compiling from the source is a bit complicated. I thought running two different versions of a program is easy on Linux (I run fedora 11 for the record). Any hint?
Thanks for reading.
On my Linux system (Ubuntu Jaunty), I have Python 2.5, 2.6 and 3.0 installed, just by installing the binary (deb) packages 'python2.5', 'python2.6' and 'python3.0' using apt-get. Perhaps Fedora packages them and names them as RPMs in a similar way.
I can run the one I need from the command line just by typing e.g. python2.6. So I can also specify the one I want at the top of my script by putting e.g.:
#!/usr/bin/python2.6
Download the python version you want to have as an alternative, untar it, and when you configure it, use --prefix=/my/alt/dir
Cheers
Nik
You're not supposed to need to run them together.
2.6 already has all of the 3.0 features. You can enable those features with from __future__ import statements.
It's much simpler run 2.6 (with some from __future__ import) until everything you need is in 3.x, then switch.
Why do you need to use make install at all? After having done make to compile python 3.x, just move the python folder somewhere, and create a symlink to the python executable in your ~/bin directory. Add that directory to your path if it isn't already, and you'll have a working python development version ready to be used. As long as the symlink itself is not named python (I've named mine py), you'll never experience any clashes.
An added benefit is that if you want to change to a new release of python 3.x, for example if you're following the beta releases, you simply download, compile and replace the folder with the new one.
It's slightly messy, but the messiness is confined to one directory, and I find it much more convenient than thinking about altinstalls and the like.