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$
Post by Charles Shapiro via Ale<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
Post by DJ-Pfulio via AlePost by Todor Fassl via AleI 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
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
_______________________________________________
Ale mailing list
http://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo
--
Ed Cashin <***@noserose.net>