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

[Xavier Morel]

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 `python_select` 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