[Python-Dev] Promoting Python 3 [was: PyPy 1.7 (original) (raw)

[Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]

Xavier Morel python-dev at masklinn.net
Wed Nov 23 08:15:10 CET 2011

On 2011-11-23, at 04:51 , Stephen J. Turnbull wrote:

Xavier Morel writes:

On 2011-11-22, at 17:41 , Stephen J. Turnbull wrote:

Barry Warsaw writes:

Hopefully, we're going to be making a dent in that in the next version of Ubuntu. This is still a big mess in Gentoo and MacPorts, though. MacPorts hasn't done anything about ceating a transition infrastructure AFAICT. What kind of "transition infrastructure" would it need? It's definitely not going to replace the Apple-provided Python out of the box, so setting python to a python3 is not going to happen. Sure, but many things do shadow Apple-provided software if you set PATH=/opt/local/bin:$PATH. Some I'm sure do, but "many" is more doubtful, and I have not seen any do that in the Python ecosystem: macports definitely won't install a bare (unversioned) python without the user asking.

I'm not sure what infrastructure is required, but I can't really see MacPorts volunteers doing a 100% conversion the way that Ubuntu's paid developers can. So there will be a long transition period, and I wouldn't be surprised if multiple versions of Python 2 and multiple versions of Python 3 will typically need to be simultaneously available to different ports. That's already the case so it's not much of a change.

It doesn't define a python3, so maybe that? A python3 symlink or script would help a little bit, but I don't think that's necessary or sufficient, because ports already can and do depend on Python x.y, not just Python x. Yes indeed, which is why I was wondering in the first place: other distributions are described as "fine" because they have separate Python2 and Python3 stacks, macports has a Python stack per Python version so why would it be more problematic when it should have even less conflicts?

Macports provide port select which I believe has the same function (you need to install the pythonselect for it to be configured for the Python group), the syntax is port select --set python $VERSION: Sure. I haven't had the nerve to do this on MacPorts because "port" is such a flaky thing (not so much port itself, but so many ports assume that the port maintainer's local configuration is what others' systems use, so I stay as vanilla as possible -- I rather doubt that many ports are ready for Python 3, and I'm not willing to be a guinea pig). That is what I'd expect as well, I was just giving the corresponding tool to the gentoo version thereof.

The problem that I've run into with Gentoo is that *even when the ebuild is prepared for Python 3* assumptions about the Python current when the ebuild is installed/upgraded gets baked into the installation (eg, print statement vs. print function), but some of the support scripts just call "python" or something like that. OTOH, a few ebuilds don't support Python 3 (or in a ebuild that nominally supports Python 3, upstream does something perfectly reasonable for Python 2 like assume that Latin-1 characters are acceptable in a ChangeLog, and the ebuild maintainer doesn't test under Python 3 so it slips through) so I have to do an eselect dance while emerging ... and in the meantime things that expect Python 3 as the system Python break.

So far, in Gentoo I've always been able to wiggle out of such problems by doing the eselect dance two or three times with the ebuild that is outdated, and then a couple of principal prerequisites or dependencies at most. Given my experience with MacPorts I very much expect similar issues with its ports. Yes I would as well, although:

  1. A bare python call would always call into the Apple-provided Python, this has no reason to change so ports doing that should not be affected
  2. Few ports should use Python (therefore assume things about Python) in their configuration/installation section (outside upstream's own assumptions): ports are tcl, not bash, so there shouldn't be too much reason to call Python from them

More information about the Python-Dev mailing list