I hate Python! [solved]

[miket]

This isn't so much of a matter of hating Python's crazy block-grouping scheme that uses whitespace instead of proper syntax, its object-orientation scheme that fails to enforce proper abstraction, or its sometimes iffy performance: it's the careless way it deals with multiple versions of the Python interepreter. In a word, Python doesn't play nicely with Gentoo slots.

In the middle of my big upgrade the ebuild for dbus-python failed. The message stated that it didn't deal with C-Python 3--even though my eselect for Python had never been set to any version of Python greater than 2.7. Responses here in the forum advised eselecting Python 3, which I did. That worked for a while--until I needed to use the equery utility and got a message about a missing module. I had the bright idea to switch things back to Python 2.7, so things worked again. Things worked OK until I got to PyQt4, which couldn't find sipconfig. I get the *strong* suspicion that if I switched back to Python 3.2 the ebuild would work but my system would be flaky.

If there is supposed to be a good way for me to deal with this, where is the news item for it? The most recent news item for Python 3 is 2.5 years old. It advised not setting the active version to 3.1 because utilities had not been ported, but it would be ready if you needed. There was also this promise:

[frostschutz]

On my ~amd64 Gentoo install it's like this:

[BillWho]

miket,

When I had conflicts with python I set it to python2.7 and ran python-updater - problem solved
_________________
Good luck

Since installing gentoo, my life has become one long emerge

[gerard27]

I've never had problems like you mention with 2.7 & 3.2.
2.7 is set according to eselect python list.
dbus-python and PyQt4 were emerged with that setting,no problem.
sip is a dependency of PyQt4-4.9.5 and plasma-workspace and pykde4.
Something wrong in your setup?
Gerard.
_________________
To install Gentoo I use sysrescuecd.Based on Gentoo,has firefox to browse Gentoo docs and mc to browse (and edit) files.
The same disk can be used for 32 and 64 bit installs.
You can follow the Handbook verbatim.
http://www.sysresccd.org/Download

[dol-sen]

I suspect you do not have USE_PYTHON set in your make.conf.

When you switched to 3.2 some things are installed there, some only in 2.7 and vice-versa

if you want to switch between the 2 and have everything capable of both 2.7 and 3.2 installed in both, then set

[miket]

I was on Python 2.7 for everything until I got to that problem with PyQt4--I don't know what would have been so strange for it that it didn't like it when I was set to Python 2.7 but did when I switched to Python 3.2. I'd be quite pleased to put everything back to Python 2.7--if I could be sure it would work.

Well, I'll give BillWho's suggestion a try: set things to Python 2.7 and run python-updater. I'm kind of inclined also to apply dol-sen's suggestion of building for both targets with USE_PYTHON (which is the Python analogue to PHP_TARGETS I thought ought to exist), but I'm afraid of how that might confuse system utilities. I'm about to try the python-updater and I'll let you know what happens.

One other thing I noticed though: on a newer system I built, Python 3.2 was installed as the default, and everything seems to work. No news item about that, alas.

[miket]

Setting the default Python to 2.7 and running python-updater did the trick. There are two things I learned while watching python-updater run:

1. I had a split setup all right--between Python 2.7 and Python 3.1. The new stuff was for Python 3.2, but there was only 3.1, not 3.2.

2. Even without USE_PYTHON, python_updater told me it was making dual targets--2.7 and 3.2--for package that are capable of that.

I still have one nagging issue: why is Python so intolerant of bytecode files of a different version? I'll grant that going from 2.x to 3.x ought to be large enough to break compatablity, but why is there never compatability between version V.m and V.m+1 files? Those Python version bumps always entail a big round of python-updater. For a language which has insinuated itself so far into systems programming, shouldn't they at least *try* to get the kind of compatability we usually see as implied by the sonames of libraries compiled from C? I wish they would be more responsible.

Since there was no change from a 2.7 slot to a 2.8 slot, I had thought there was no need for the python-updater. Evidently, it is what would have saved me when I hit that problem with PyQt4.