Re: PyCon BoF: Stretch goals for cPython, PyPy & CFFI

[Scott Kitterman <debian@kitterman.com>]

On Tuesday, April 14, 2015 09:22:22 AM Thomas Kluyver wrote:
> On 14 April 2015 at 08:57, Scott Kitterman <debian@kitterman.com> wrote:
> > I have scripts I use locally that are untouched in almost a decade that
> > use
> > /usr/bin/python.
> 
> I'm thinking about scripts that are written and distributed to people
> running on different, unknown, Linux distros. Obviously if you're only
> targeting your own machines, there's no problem. But if you want to write a
> script that will work for arbitrary Linux users, what should you do? I
> imagine it's not yet a safe assumption that python3 is installed
> everywhere, but on the other hand, Ubuntu and Fedora are both looking at
> dropping Python 2, so without some kind of compatibility shim it won't be
> safe to assume there's a python command.

I'm using myself as a stand in for users generally in this example.  I'm sure 
I'm not alone in this.  Making /usr/bin/python point at python3 is just bad 
design.

It is, as I think it was you said, easy enough to write Python code these days 
that works for both python and python3.  As an upstream developer, go ahead 
and do that and leave it to the distros to packageit appropriately for their 
environment.

In the case of Debian/Ubuntu, if something needs python (vice python3), it 
should have proper dependencies declared.  What's there or not by default 
doesn't matter.

I don't think it's possible to have something that at runtime call python2.7 
or python3 based on what's in the code.  The only thing it could select based 
on is what's in the shebang and that helps not at all because if the shebang 
isn't /usr/bin/python the launcher won't get called and if it is, you have to 
assume it's python2.7 that's meant.

Scott K