I'm very sympathetic to "use python2." I still use python2. But we should all keep in mind the "no shit really this time" EOL for python is 2020. http://legacy.python.org/dev/peps/pep-0373/ Even if you say "well, it'll just be forked," you don't really know how many forks and pain there will be. Maybe python2 will be like LibreOffice, or maybe it will be like OpenOffice. Like it or not, python3 is the future.
Introduction to Python for Computational Science and Engineering [pdf]
21–30 of 55 posts
Re: Introduction to Python for Computational Science and Engineering [pdf]
#22> As Python 2.x is still the default Python on many system and there are a fair number of research codes out there based on Python 2, we will use Python 2.x in this book. This is so unfortunate. Scientific computing is riddled with technical debt and starting with Python 2 today is fairly irresponsible. If you're already invested in Python 2 and have code/training written up, fine. But if you're learning it just now,…
I'd be happy to hear examples how Python 3 helps us in computational sciences. I've barely even tried it before and have used Python 2 a lot.
Sir/Madam, I am here to make you happy then. Python 3's multiprocessing library is leaps and bounds "better" than python 2's. By "better", I mean faster(in my workloads) by 30-40%. If time is money, then that feature alone saves you both.
Re: Introduction to Python for Computational Science and Engineering [pdf]
#23https://en.wikipedia.org/wiki/Narcissism_of_small_difference...
If the authors of a textbook made the decision to use 2.7, it's good enough for anyone.
Re: Introduction to Python for Computational Science and Engineering [pdf]
#24Re: Introduction to Python for Computational Science and Engineering [pdf]
#25> As Python 2.x is still the default Python on many system and there are a fair number of research codes out there based on Python 2, we will use Python 2.x in this book. This is so unfortunate. Scientific computing is riddled with technical debt and starting with Python 2 today is fairly irresponsible. If you're already invested in Python 2 and have code/training written up, fine. But if you're learning it just now,…
Re: Introduction to Python for Computational Science and Engineering [pdf]
#26Re: Introduction to Python for Computational Science and Engineering [pdf]
#27> As Python 2.x is still the default Python on many system and there are a fair number of research codes out there based on Python 2, we will use Python 2.x in this book. This is so unfortunate. Scientific computing is riddled with technical debt and starting with Python 2 today is fairly irresponsible. If you're already invested in Python 2 and have code/training written up, fine. But if you're learning it just now,…
I'd be happy to hear examples how Python 3 helps us in computational sciences. I've barely even tried it before and have used Python 2 a lot.
C = A@B
vs C = A.dot(B)Re: Introduction to Python for Computational Science and Engineering [pdf]
#28Earlier quoted context omitted.
I actually see np.dot(np.dot(x,y),z) as easier to read and remember. It is more explicit in what it is doing. Being explicit is a good thing.
a + 4*(x-y) + b**5 vs (+ a (* 4 (- x y )) (expt b 5 )) Sometimes, as arithmetic with lisp shows, conciseness is better. Also, it isn't being more explicit than it is being more verbose .
This is implicit in
a + b ** 5
according to a precedence rule between the and + operator, which is hidden in the parser's implementation and in documentation thereof.Well, the white-spacing
a + b**5
suggests it. But the suggestions produced by insignificant whitespace can be mere wishful thinking: int* x, y; // two C pointers? not!
Speaking of whitespace, also have the advantage of there being multiple ways to split the expression into multiple lines, all conforming to a very clear, simple formatting rule: (+ a
(* 4 (- x y))
(expt b 5))
(+ a
(* 4
(- x y))
(expt b 5))
Fully expanded, every term on separate line: (+ a
(* 4
(- x
y))
(expt b
5))
In this manner, we can write complex expressions that would be quite unreadable in infix, requiring break-up into intermediate temporaries.We almost have a circuit diagram now with "gates" for the operations: a three input + gate, etc:
____
/ |- a
| | ____
--| + |-----/ |- 4
| | | * | ____
\____|- | |-----/ |- x
` \____| | - |
| \____|- y
| _____
`--/ |- b
| expt|
\_____|- 5Re: Introduction to Python for Computational Science and Engineering [pdf]
#29> As Python 2.x is still the default Python on many system and there are a fair number of research codes out there based on Python 2, we will use Python 2.x in this book. This is so unfortunate. Scientific computing is riddled with technical debt and starting with Python 2 today is fairly irresponsible. If you're already invested in Python 2 and have code/training written up, fine. But if you're learning it just now,…
Python 2 is /usr/bin/python Python 3 is /usr/bin/python
If on Windows and you have both python 2.7 and python 3.x installed, just just use the py command to automatically select the correct runtime. I think you may need to specify the shabang for this to work (i.e. "#!/usr/bin/env python" for a 2.x script and "#!/usr/bin/env python3" for a 3.x script).
Despite some recent discussions lamenting slow adoptions, everyone I know and myself write all new code in 3.5.x and only fall back to 2.7 for legacy code or when you need a module that is not yet 3.x compatible. Problem is I work at a small company with about 10 devs. If a 2.x script works, we have zero incentive to port it to 3.x because we have such a huge backlog of work items.
Re: Introduction to Python for Computational Science and Engineering [pdf]
#30Earlier quoted context omitted.
I'm a hardcore proponent of Python 3 (because it's the only Python I've ever used/learned), but I'm OK with this book accepting the realities and for at least committing to writing 3.x compatible code: > However, we will write code that is as much as possible in the Python 3 style (and understood by Python 2). The most prominent example is that in Python 2.x, the print command is special where as in Python 3 it is an…
Reduce is easy to fix also, but that ignores the entire reasoning for it being removed and only serves to highlight the massive chasm between 2 and 3. The clean break of 3 and the sanity it brings to the language is undeniable.
Well, I can't deny they broke it, but sanity is pretty deniable. Python has always been a dynamic language, and one of the core mantras was "there should be one obvious way to do it" (in contrast to Perl). All the new type annotation stuff and the multiple ways to handle string formatting are steps in very weird directions. Maybe they should make a Python version 4 to clean some of that mess up.