I have a friend who teaches Python to beginners and uses it for
scientific programming, so I'll see what he says. The biggest holdup
in Python 3 adoption has been third-party dependencies, especially for
applications that use a lot of them. Pyramid has a lot of dependencies
because it was designed to use "best of breed" libraries rather than
reimplementing their functionality. But Pyramid has been Python 3
compatible since near its first release around 2010. SQLAlchemy and
Mako soon followed, and that covers the largest percentage of Pyramid
applications. Pyramid later unbundled non-essential features like
'pyramid_mako', so it has even fewer dependencies now. I have ported
two Pylons applications to Pyramid and Python 3, a third is ported to
3 but not fully tested there yet, and a fourth that is still in Pylons
and Python 2 and will probably be converted to Javascript. In all
cases the problems were third-party libraries that weren't Python 3
compatible yet, or finding time to convert the application.
My friend the teacher does complain about how Python 3 forces the
separation of strings and bytes: why not leave it as it was? So he
would be sympathetic to that argument, and he preferred to stick with
Python 2, but he's now migrating to 3 because it's the future.
"The Case Against Python 3" is 95% hysterical rant and 5% accurate
critiques. But none of the critiques are fatal to Python 3; they're
just things that could have been handled better. Zed's argument starts
from a rigid and rather esoteric position, and anything that doesn't
match that position is wrong. So the ultimate problem is Zed's
position and criteria, which many people would disagree with.
Is Python 3 dead? No, it recently reached the tipping point of
accelerating adoption. Is it really only at 30%? Where did he get that
figure from? It's impossible to know how many programs are running in
Python 3 vs 2 because users aren't required to register them. It's
also too early to tell 2020 is a realistic cutoff for Python 2
support. Maybe it will be extended, maybe not.
Python has had several false starts during its evolution. The '2to3'
translator, the string formatting functions, and the string/unicode
problems are just three of them. But expecting every decision to be
perfect requires a 100% reliable crystal ball. The developers
initially assumed most people would use '2to3'. But most people
eventually found they could get 90% of the way with Python 2/3
compatible code, and use something like 'six' to bridge the gap.
There's also '3to2' now, as people realize it makes more sense to
write forward-compatible code now and just back-translate temporarily.
Zed ignores the reasons for the changes. Python's developers believe
Python 2's hybrid behavior was a horrible mistake, and it causes
obscure exceptions far away from where the variable was set. The
change was to make Python more reliable and predictable. Zed makes a
usability argument that changes should focus on the user's desires,
not on the developers' desires. But this really was a case where it
helps users in important ways even if they don't realize it at first,
and it's the only way to get rid of the sloppiness in Python's
behavior that led to those obscure exceptions. Zed is asking for the
Python 2 behavior to be included in Python 3, but that also means
re-enabling all those obscure exceptions that kept users spending
nights awake trying to figure out what was wrong with their program. A
hard UnicodeDecodeError/UnicodeEncodeError earlier is easier to
troubleshoot, and functions like 'pyramid.compat.text_' and
'pyramid.compat.binary_' can guarantee you'll have str or bytes even
if the origin is unreliable.
PEPs 528 and 529 refer to incompatible differences between how Windows
and Unix interpret filename strings and console I/O strings. This
requires an approach that can work on all these platforms. It's not a
general string/unicode hybrid model, and re-introducing the
ambiguities between the two would only make things worse.
A "Turing machine" is an imaginary concept. It has infinite memory
("the tape")., or at least it can create unlimited memory on demand.
"Turing complete" means a language has minimum control structures
(if-then, loop-break). Python has these with its 'if-then' and 'while
True: break' constructs. It does not mean that any particular virtual
machine must be able to run foreign languages. It means that you must
be able to write a Python program that emulates another language. Of
course you can. It just means it will just be using that program's
"virtual machine" rather than the Python virtual machine directly.
The string formatters came about because users were dissatisfied with
the previous ones. They did not appear one right after the other,
there were several years between each. Arguably the new f"abc{foo}def"
should have been the original one -- but we can't even say that
because not enough people are using Python 3.6 yet to verify this.
That's enough critique for now.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/pylons-discuss/CAFmXjSDn72hbPuF50ppbjL5z8VKm61o10TiG8khAMrF-40pc%2Bw%40mail.gmail.com.
Mike Orr <
slugg...@gmail.com>