<div dir="ltr">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.<div><br></div><div>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".</div><div><br></div><div>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.</div><div><br></div><div><div>(normal) bash$ ipython</div><div>Python 2.7.10 (default, Oct 23 2015, 19:19:21) </div><div>Type "copyright", "credits" or "license" for more information.</div><div><br></div><div>IPython 2.2.0 -- An enhanced Interactive Python.</div><div>? -> Introduction and overview of IPython's features.</div><div>%quickref -> Quick reference.</div><div>help -> Python's own help system.</div><div>object? -> Details about 'object', use 'object??' for extra details.</div><div><br></div><div>In [1]: from __future__ import print_function</div><div><br></div><div>In [2]: print(11 / 10)</div><div>1</div><div><br></div><div>In [3]: </div><div>Do you really want to exit ([y]/n)? y</div><div><br></div><div>(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.)</div><div><br></div><div>Now switch to Python 3.</div><div><br></div><div>(normal) bash$ . ~/environments/py36/bin/activate</div><div><br></div><div>(py36) bash$ ipython</div><div>Python 3.6.2 (default, Sep 25 2017, 14:00:54) </div><div>Type 'copyright', 'credits' or 'license' for more information</div><div>IPython 6.2.1 -- An enhanced Interactive Python. Type '?' for help.</div><div><br></div><div>In [1]: from __future__ import print_function</div><div><br></div><div>In [2]: print(11 / 10)</div><div>1.1</div><div><br></div><div>In [3]: </div><div>Do you really want to exit ([y]/n)? </div><div>(py36) bash$ </div></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 25, 2018 at 7:32 AM, Charles Shapiro via Ale <span dir="ltr"><<a href="mailto:ale@ale.org" target="_blank">ale@ale.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>Another Correct way to specify the interpreter is:<br><br></div><code><br></div>#!/usr/bin/env python<br></div></code><br><br></div>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.<br><br></div><div>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.<br><br><br></div>-- CHS<br><br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 24, 2018 at 10:08 PM, DJ-Pfulio via Ale <span dir="ltr"><<a href="mailto:ale@ale.org" target="_blank">ale@ale.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 01/24/2018 06:03 PM, Todor Fassl via Ale wrote:<br>
> I got a question from a student who is using python. "I'd rather not<br>
> hard code in any python version. Is there any reason to have the system<br>
> default be 2 instead of 3?"<br>
><br>
> He had asked me to install the python-matplotlib package. I was like,<br>
> "Are you sure you want python-matplotlib and not python3-matplotlib?" He<br>
> is still coding in python2.7 instead of python3 but not by choice. Is<br>
> there such a thing as a system default python version? To program in<br>
> python3, doesn't he have to modify his code?<br>
><br>
<br>
</span>There are 2 major ways for python versions to be decided.<br>
<br>
a) If you are making an application that needs to run on every OS, then<br>
the developer should specify the exact version necessary and provide any<br>
libs needed for it. It should be self-contained and not dependent on<br>
whatever the OS python or OS python libraries happen to be. Ruby and<br>
perl both provide tools for self-contained deployments in this way.<br>
Python definitely does as well.<br>
<br>
b) If you are making an application to be added to an existing OS, then<br>
the platform/distro decides the version and everything you code should<br>
work with that version and the libraries provided for it through the<br>
package manager.<br>
<br>
I read somewhere that Ubuntu will be switching to Python3 as the primary<br>
platform version in 18.04. <a href="https://wiki.ubuntu.com/Python" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/Python</a><br>
<br>
[quote]All Ubuntu/Canonical driven development should be targeting<br>
Python 3 right now, and all new code should be Python 3-only.<br>
[/quote]<br>
<div class="m_33819003664149485HOEnZb"><div class="m_33819003664149485h5">______________________________<wbr>_________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org" target="_blank">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/li<wbr>stinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/li<wbr>stinfo</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/<wbr>listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/<wbr>listinfo</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"> Ed Cashin <<a href="mailto:ecashin@noserose.net" target="_blank">ecashin@noserose.net</a>></div></div>
</div>