[Python-ideas] Migration of /usr/bin/python to python3

[M.-A. Lemburg]

On 12.03.2015 01:59, Andrew Barnert wrote:
> On Mar 11, 2015, at 5:19 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>>
>>> On 11.03.2015 23:45, Andrew Barnert wrote:
>>>> On Mar 11, 2015, at 1:38 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>>
>>>>> On 11.03.2015 21:03, David Mertz wrote:
>>>>> https://www.python.org/dev/peps/pep-0394/
>>>>
>>>> I think the migration should start with modifying scripts to use
>>>>
>>>> #!/usr/bin/env python2
>>>>
>>>> when they are Python 2 only (*) and
>>>>
>>>> #!/usr/bin/env python3
>>>>
>>>> when they are Python 3 only and
>>>>
>>>> #!/usr/bin/env python
>>>>
>>>> only when they support both Python 2 and 3.
>>>
>>> Except that you need a step 0: Not every system out there is PEP 394-compliant. Most notably, the built-in Python on OS X has nothing named python2, and python is a wrapper executable that selects between python2.5, python2.6, and python2.7. Some of the popular third-party Python-with-extra-batteries installs still give you only python and maybe python2.7, but not python2. And most linux distros' built-in and standard repo Pythons are PEP 394-compliant, but "most Linux distros" is not the same thing as "all non-OS X Unix-like systems".
>>>
>>> So if you want to move this forward, I think someone needs to create a central place with all the info on how far we are from 100% PEP 394 compliance (including but reports to each vendor, etc.) and start pressuring the vendors who don't comply.
>>>
>>> In the case of Apple, unless you can get them to add a python2 executable in bug fix releases of 10.9 and 10.10, rather than just in 10.11, it'll be a long time before python2 becomes a portable command. (Even if you could, would dropping OS X 10.6-10.8 be acceptable today for most scripts?)
>>
>> I won't comment on the Mac Python installations. There's a reason
>> why we've been using our own installations since the early days of
>> Max OS X :-)
> 
> In the early days of Mac OS X, Apple shipped an incomplete and broken version of a 4-year-old Python, so that made perfect sense. For half a decade, Apple has been shipping a complete version of the latest 2.x, and with things like PyObjC available out of the box. On top of that, when you tell people to use a separate Python 2.7 installation, they invariably run into problems where they install things for Apple's Python and then try to use them in the other Python or vice-versa, which is compounded by the fact that many people want to use /usr/local/bin as their script directory, but that's the same directory Apple uses, which is one of the ways you get to Ian's problem--whichever ipython was installed last wins--but of course here version numbers don't even help because they're both 2.7. There are hundreds of people on StackOverflow with this problem every year, and surely orders of magnitude more who don't go there for help.

As I said, we've been using our own installations. That doesn't
mean the resulting packages won't run with the stock Apple
versions, it just means that we're not relying on those Apple
versions when compiling our software.

> The root problem is that PEP 394 only solves the problem of having two different versions of Python, not two different Pythons of the same version, but you're encouraging people to do the latter. And if PATH doesn't solve it for them (because they're using /usr/local), what does?

This thread is not trying to solve the problem of having
multiple Python installations of the same version. The subject problem
is migration to Python 3, not running multiple installations
of Python 2.7. Let's not get side tracked (I know it's python-ideas
and side tracking is fun, but still :-)).

> Also, if your program only works on Macs with an extra Python installation, then you don't work on the majority of Unix desktops out there, and it's hard to call that "portable". If you're not interested in working out of the box on most *nix systems, just require Python 3 and all these problems go away. :)

Actually, we don't work much on Macs, but mostly on Linux,
FreeBSD and also on Windows, where you have a different set of problems
than what's being discussed here, but which can be solved in a
similar way by the way of the py launcher:

https://www.python.org/dev/peps/pep-0397/

With the right py.ini file, the above approach will work on Windows
as well.

>> In any case, if those binaries don't exist on the target system,
>> the user will get a nice error message saying e.g.:
>>
>> python2: Command not found.
>>
>> and even better: modern OSes will then point the user to the
>> missing packages on their system to make the script run again.
> 
> So nothing other than some of the linux distros counts as a modern OS?

Of course they do. This was just a tangent I couldn't resist,
since I think that more modern OSes should provide the same usability
features. It's one of the nice Linux distro features I'd love to
see in other OSes as well.

But this was not the main argument. I think that even the simple

python2: Command not found.

is better than the standard Python SyntaxError (or other
similar Python 3 vs. 2 related error) you get when running
a script with the wrong Python version.

>> I think that's a lot more informative than
>>
>> SyntaxError: Missing parentheses in call to 'print'
>>
>> :-)
>>
>> Anyway, the above is just what I recommend.
>>
>> I'm not a big fan of doing setuptools like magic all over the
>> place when there's a clean solution right in front of you (ok,
>> one may need to take off those cool Python monkey-patching and
>> meta-class sunglasses occasionally to see it ;-)).
>>
>>>> "Explicit is better than implicit" and all that Zen :-)
>>>>
>>>> Once that's done, switching the symlink is really a no-brainer.
>>>>
>>>> The recipe for this is easy too:
>>>>
>>>> 1. replace all "#!/usr/bin/env python" with "#!/usr/bin/env python2"
>>>> 2. migrate your scripts one by one to either Python 3.x or
>>>>  to Python 2.7 + 3.4+
>>>> 3. after migration replace "#!/usr/bin/env python2" with
>>>>  "#!/usr/bin/env python3" or "#!/usr/bin/env python" resp.
>>>>
>>>> (*) Some OSes may require to use python2.7, if they don't come
>>>> with a symlink from python2 -> python2.7.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 12 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> mxODBC Plone/Zope Database Adapter ...       http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::::: Try our mxODBC.Connect Python Database Interface for free ! ::::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/