Can I use Python 2.7 modules from Python 2.6? Or do something to achieve the same effect?
I'm limited to use Python 2.6, but an issue exists in the subprocess module provided by Python 2.6. This is fixed in Python 2.7. I'm curious if I rig this up using pip (or equivalent) to sidestep the bug temporarily until upgrading one day. How would I go about doing this?
Yes, usually. The difference between 2.6 and 2.7 isn't very big, as 2.7 is supposed to be a bridge between 2.6 and 3.0. As a result, most Python modules for 2.7 will work in both of these versions (usually better in 2.6 than 3.0).
Of course, the only surefire way to know the answer is to try!
EDIT: To be clear, I do not recommend that you do this at all, if you have a choice.
Hacking around a Python installation just because of a Python bug in one module is a bad idea.
If you really want to stay on Python 2.6, but also want to fix this bug, I might suggest compiling Python 2.6 from source, but also applying the relevant bug fix code to the subprocess module from 2.7.
You will end up with a custom build of Python 2.6. Of course, if you're stuck on the standard 2.6 because you are unable to install any different version, then this won't help.
Etienne Perot suggested using a Python 3.2 subprocess backport available at http://code.google.com/p/python-subprocess32/ instead of hacking around the Python installation.
This let me install the module into my virtual environment's site-packages, and patch the subprocess code with http://hg.python.org/cpython/rev/767420808a62 to fix the bug mentioned in question. Afterwards, a simple import subprocess32 as subprocess fixed the problem.
Related
I am using a VS Code (Linux Mint) plug-in for Python that allows me to choose between different interpreters.
When I run my file with Python 3.8, I get an error saying that it can't find pandas I am trying to use, but when I switch the interpreter to Python 3.6 there is no issue finding pandas.
What's going on?
The module might not be updated for Python 3.8. Search up the module's name from GitHub or where it can be imported from to see what versions they support.
That module isn't installed for Python 3.8, simple as that. Different versions of Python have different libraries (listed under sys.path) on Debian-based distros.
Without knowing which module, it's hard to say much else, like whether it even supports 3.8, but to install it, you might be able to use apt or pip.
I did a quick research into documentation and did not find any evidence that suggests argparse is supported before 2.6. We have development network as well as servers that use Python 2.5.1 to do a lot of things. I had an idea to upgrade it, but didn't realise that there is a change request process that needs to be gone through. I am wondering if I can have an alternative method to use something similar to argparse.
I know optparse is the other option, but it is also deprecated in 2.7.x versions. Does anyone know anything else?
argparse is included with Python from version 2.7 onwards.
You can install it from PyPI for earlier versions of Python, Python 2.3 and up is supported.
Based on discussions that I've seen on the Python bug issue site, optparse is not really deprecated. Don't expect further development, but it isn't going to disappear any time soon.
All of argparse is contained in one file, argparse.py. So you could grab that from almost anywhere, and put it on your load path. A possible exception is a recent Python3 version that has a gratuitous (IMO) 'nested-with' statement.
It's possible that there are other incompatibilities with Python 2.5, but it wouldn't be hard to test a 2.7 argparse.py in the 2.5 environment.
There is also a unittesting Lib/test/test_argparse.py file. Though that is more likely to be incompatible, since it is using some newer unittest functionality.
What problems can I have if I will use python 2.7 instead python 2.6 for my pylons/pyramid projects? Before I use python 2.6 on my ubuntu 10.04 but now I have ubuntu 11.04 on my laptop with python 2.7.
If you're using Ubuntu the package manager will fix most of the minor issues such as finding the packages you used to have in 2.6.
But there are some Packages that isn't compliant with Python2.7.
Mainly Python2.7 is a backwards compatible version from 3.X, or at least Python 2.7 was an upgrade from 2.6 towards the 3.X syntax and all it's new functions while the translation to 3.X was made.
Here's some info:
http://docs.python.org/dev/whatsnew/2.7.html
http://www.python.org/getit/releases/2.7/
Mainly Python2.7 should just give you more functions but can cause unexpected problems,
Go ahead and upgrade it on a seperate machine, run your code, if it works, upgrade your real machine to Python2.7.
The problems that might occur are minor, you should be able to fix them within 1h.
According to this post, Pyramid 1.2 (as is 1.1) is fully supported on Python 2.5.x, 2.6.x, and 2.7.x so you should be all set. From my own personal experience,I haven't run into any issues with Pyramid/Python2.7.
These days my Pyramid stack consists of:
python 2.7
khufu
sqlalchemy 0.7.x
and it works quite well.
Take a look at http://docs.python.org/dev/whatsnew/2.7.html
You'll find what all you'll ever need to know.
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.
After going through hell trying to install the latest version of postgresql and psycopg2 today I'm going for a complete reinstall of Leopard.
I've been sticking with macpython 2.5 for the past year but now I'm considering macports even 2.6
For me it's most important for Twisted, PIL and psycopg2 to be working without a problem.
Can anyone give some guidelines for what version I should choose, based on experience?
Edit:
Ok I've decided to go without reinstalling the os. Hacked around to clean up the bad PostgresPlus installation and installed another one. The official python 2.6.1 package works great, no problem installing it alongside 2.5.2. Psycopg2 works. But as expected PIL wont compile.
I guess I'll be switching between the 2.5 from macports and the official 2.6 for different tasks, since I know the macports python has it's issues with some packages.
Another Edit:
I've now compiled PIL. Had to hide the whole macports directory and half the xcode libraries, so it would find the right ones. It wouldn't accept the paths I was feeding it. PIL is notorious for this on leopard.
You can install them side-by-side. If you've encounter problems just set python 2.5 as the standard python and use e.g. python26 for a newer version.
Read this
http://farmdev.com/thoughts/66/python-3-0-on-mac-os-x-alongside-2-6-2-5-etc-/
I still use macports python25, because so many other packages depend on it, and have not updated to use python26.
$ port dependents python25
gnome-doc-utils depends on python25
mod_python25 depends on python25
postgresql83 depends on python25
gtk-doc depends on python25
at-spi depends on python25
gnome-desktop depends on python25
mercurial depends on python25
And that's excluding the py25-* packages I have installed.
I wrote something today on this very subject, my recommendation? Run multiple version, and slap virtualenv down to compartmentalize things.
http://jessenoller.com/2009/03/16/so-you-want-to-use-python-on-the-mac/
I also wouldn't both with macports. I don't see a need for it.
I've updated my macbook running leopard to python 2.6 and haven't had any problems with psycopg2. For that matter, I haven't had any compatibility issues anywhere with 2.6, but obviously switching to python3k isn't exactly recommended if you're concerned about backwards compatibility.
I would stick with the MacPython version 2.5.x (I believe 2.5.4 currently). Here's my rationale:
Snow Leopard may still be on the 2.5 series, so you might as well be consistent with the future OS (i.e. no point in going too far ahead).
For most production apps, nobody is going to want to use 2.6 for another year.
No frameworks/programs are going to leave 2.5 behind for at least 2 years.
In other words, my approach is that the only reason to do 2.6 is for fun. If you're looking to have fun, just go for 3.0.
I use both Twisted and Psycopg2 extensively on OSX, and both work fine with Python 2.6. Neither has been ported to Python 3.0, as far as I know.
Several of Python 3.0's features have been back-ported to 2.6, so you gain quite a bit by moving from 2.5 to 2.6. But I wouldn't switch to 3.0 until all of your thirdparty libraries support it; and this may not happen for some time.
I had some trouble installing PIL. I compiled it and it worked with the modification explained on this post http://passingcuriosity.com/2009/installing-pil-on-mac-os-x-leopard/
After that it worked fine.
I am using Python 2.5.1. It's working great for me for general scripting and some CherryPy web projects.
If your using Macports, I recommend downloading the python_select package, which facilitates easy switching between different versions including the built in apple versions. Makes life a lot easier.