[ale] Slightly OT: System default python version

Ed Cashin ecashin at noserose.net
Thu Jan 25 08:55:45 EST 2018


But this might be a good opportunity for education.  The "I don't want to
hard code the specifics" inclination probably comes from a principle that
the student has just learned.  It is true that when there is no advantage
to hard-coding externalities, one should avoid it.  That way you don't get
"tight coupling" without need, and you have more modularity, more reusable
components.

However, sometimes the externalities matter a lot.  In this case, Python 2
and 3 are different enough that I don't think it's safe to write toward an
abstraction "#! /usr/bin/env python".

You could try, by writing lowest-common-denominator code, but it would be
dangerous, because anyone coming to your code later (or your future self)
would not necessarily know about tricky situations.  For example, below you
get two answers from the same simple arithmetic expression.  It is probably
better to hard-code *at least* the fact that it's either Python 2 or 3
code, because tightly coupling the code to the interpreter is safer and
more simple in this case.  Python 2 and 3 are not really the same
interpreter.

(normal) bash$ ipython
Python 2.7.10 (default, Oct 23 2015, 19:19:21)
Type "copyright", "credits" or "license" for more information.

IPython 2.2.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: from __future__ import print_function

In [2]: print(11 / 10)
1

In [3]:
Do you really want to exit ([y]/n)? y

(That thing about importing from future is the kind of stuff the student
would have to get used to if trying to support 2 and 3.)

Now switch to Python 3.

(normal) bash$ . ~/environments/py36/bin/activate

(py36)  bash$ ipython
Python 3.6.2 (default, Sep 25 2017, 14:00:54)
Type 'copyright', 'credits' or 'license' for more information
IPython 6.2.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: from __future__ import print_function

In [2]: print(11 / 10)
1.1

In [3]:
Do you really want to exit ([y]/n)?
(py36) bash$



On Thu, Jan 25, 2018 at 7:32 AM, Charles Shapiro via Ale <ale at ale.org>
wrote:

> Another Correct way to specify the interpreter is:
>
> <code>
> #!/usr/bin/env python
> </code>
>
> Guarantees that you'll get the first "python" in ${PATH}.  On most
> Debian-based systems, that is a softlink to the current default version. On
> my Slink (yeah, I know, I'm updating soon) it goes to "/usr/bin/python",
> which is a symlink to "/usr/bin/python2.7".  It may also be a symlink to a
> symlink in /etc/alternatives.
>
> This is really a bash thing rather than a python thing. The trick is to
> get the bash interpreter to invoke the correct program to run your script,
> be it python, perl, or another language.
>
>
> -- CHS
>
>
> On Wed, Jan 24, 2018 at 10:08 PM, DJ-Pfulio via Ale <ale at ale.org> wrote:
>
>> On 01/24/2018 06:03 PM, Todor Fassl via Ale wrote:
>> > I got a question from a student who is using python. "I'd rather not
>> > hard code in any python version. Is there any reason to have the system
>> > default be 2 instead of 3?"
>> >
>> > He had asked me to install the python-matplotlib package. I was like,
>> > "Are you sure you want python-matplotlib and not python3-matplotlib?" He
>> > is still coding in python2.7 instead of python3 but not by choice. Is
>> > there such a thing as a system default python version? To program in
>> > python3, doesn't he have to modify his code?
>> >
>>
>> There are 2 major ways for python versions to be decided.
>>
>> a) If you are making an application that needs to run on every OS, then
>> the developer should specify the exact version necessary and provide any
>> libs needed for it. It should be self-contained and not dependent on
>> whatever the OS python or OS python libraries happen to be. Ruby and
>> perl both provide tools for self-contained deployments in this way.
>> Python definitely does as well.
>>
>> b) If you are making an application to be added to an existing OS, then
>> the platform/distro decides the version and everything you code should
>> work with that version and the libraries provided for it through the
>> package manager.
>>
>> I read somewhere that Ubuntu will be switching to Python3 as the primary
>> platform version in 18.04. https://wiki.ubuntu.com/Python
>>
>> [quote]All Ubuntu/Canonical driven development should be targeting
>> Python 3 right now, and all new code should be Python 3-only.
>> [/quote]
>> _______________________________________________
>> Ale mailing list
>> Ale at ale.org
>> http://mail.ale.org/mailman/listinfo/ale
>> See JOBS, ANNOUNCE and SCHOOLS lists at
>> http://mail.ale.org/mailman/listinfo
>>
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
>


-- 
  Ed Cashin <ecashin at noserose.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20180125/22173a1a/attachment.html>


More information about the Ale mailing list